mirror of
https://github.com/swift-server/swift-aws-lambda-runtime.git
synced 2026-06-02 07:27:33 +00:00
9f566bf4f1
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>
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 BalancerAPIGatewayV2Request- for requests from API Gateway V2
Based on the successfully decoded type, it returns an appropriate response.
Building
swift package archive --allow-network-connections docker --base-docker-image swift:amazonlinux2023
Deploying
Deploy using SAM:
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:
curl https://<api-id>.execute-api.<region>.amazonaws.com/apigw/test
Expected response:
{"source":"APIGatewayV2","path":"/apigw/test"}
Test ALB:
curl http://<alb-dns-name>/alb/test
Expected response:
{"source":"ALB","path":"/alb/test"}
How It Works
The handler uses Swift's type-safe decoding to determine the event source:
- Receives raw
ByteBufferevent - Attempts to decode as
ALBTargetGroupRequest - If that fails, attempts to decode as
APIGatewayV2Request - Returns appropriate response based on the decoded type
- Throws error if neither decoding succeeds
This pattern is useful when a single Lambda function needs to handle requests from multiple sources.