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>
66 lines
1.6 KiB
Markdown
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.
|