Files
swift-aws-lambda-runtime/Examples/MultiSourceAPI/README.md
T
Sébastien Stormacq 9f566bf4f1 [plugin] Display a warning when compiling on Amazon Linux 2 and optin documentation and examples for Amazon Linux 2023 (#668)
This PR has been reworked. Instead of silently switching the default
base image based on Swift version, we now:

1. **Keep Amazon Linux 2 as the default** base Docker image for the
packager plugin
2. **Add a prominent deprecation warning** when AL2 is used (either via
Docker or natively), informing developers that AL2 reaches End of Life
on June 30, 2026
3. **Migrate all examples** (READMEs, SAM templates, scripts) to build
and deploy on Amazon Linux 2023 (`provided.al2023` runtime +
`--base-docker-image swift:amazonlinux2023`)
4. **Update documentation** (readme, quick-setup) with migration notes

The warning includes the `--base-docker-image swift:6.3-amazonlinux2023`
flag and reminds developers to use the `provided.al2023` runtime when
deploying.

After June 30, 2026, the default will switch to AL2023.

---

<details>
<summary>Original PR description (superseded)</summary>

~~Now that Docker Hub has official Swift images based on Amazon Linux
2023 (starting with 6.3), the packager plugin picks the right base image
automatically depending on the Swift version:~~
~~- Swift 6.3 and later: `swift:<version>-amazonlinux2023`~~
~~- Earlier versions: `swift:<version>-amazonlinux2` (unchanged
behavior)~~
~~- No version specified (latest): defaults to `amazonlinux2023`~~

~~When only a major version is provided (e.g. `--swift-version 6`
without a minor), we conservatively treat it as 6.0 and use Amazon Linux
2, since we can't be sure it's 6.3+.~~
~~Also added a verbose log line showing the resolved Swift version,
Amazon Linux version, and final base image to help with debugging.~~
~~The `--base-docker-image` flag still overrides everything as before.~~

</details>

---------

Co-authored-by: Sébastien Stormacq <stormacq@amazon.lu>
2026-05-28 10:26:44 +02:00

66 lines
1.6 KiB
Markdown

# Multi-Source API Example
This example demonstrates a Lambda function that handles requests from both Application Load Balancer (ALB) and API Gateway V2 by accepting a raw `ByteBuffer` and decoding the appropriate event type.
## Overview
The Lambda handler receives events as `ByteBuffer` and attempts to decode them as either:
- `ALBTargetGroupRequest` - for requests from Application Load Balancer
- `APIGatewayV2Request` - for requests from API Gateway V2
Based on the successfully decoded type, it returns an appropriate response.
## Building
```bash
swift package archive --allow-network-connections docker --base-docker-image swift:amazonlinux2023
```
## Deploying
Deploy using SAM:
```bash
sam deploy \
--resolve-s3 \
--template-file template.yaml \
--stack-name MultiSourceAPI \
--capabilities CAPABILITY_IAM
```
## Testing
After deployment, SAM will output two URLs:
### Test API Gateway V2:
```bash
curl https://<api-id>.execute-api.<region>.amazonaws.com/apigw/test
```
Expected response:
```json
{"source":"APIGatewayV2","path":"/apigw/test"}
```
### Test ALB:
```bash
curl http://<alb-dns-name>/alb/test
```
Expected response:
```json
{"source":"ALB","path":"/alb/test"}
```
## How It Works
The handler uses Swift's type-safe decoding to determine the event source:
1. Receives raw `ByteBuffer` event
2. Attempts to decode as `ALBTargetGroupRequest`
3. If that fails, attempts to decode as `APIGatewayV2Request`
4. Returns appropriate response based on the decoded type
5. Throws error if neither decoding succeeds
This pattern is useful when a single Lambda function needs to handle requests from multiple sources.