Sébastien Stormacq
262c3b539a
Revert streaming codable handler change and propose it as an example instead of an handler API. **Motivation:** I made a mistake when submitting this PR https://github.com/swift-server/swift-aws-lambda-runtime/pull/532 It provides a Streaming+Codable handler that conveniently allows developers to write handlers with `Codable` events for streaming functions. This is a mistake for three reasons: - This is the only handler that assumes a Lamba Event structure as input. I added a minimal `FunctionUrlRequest` and `FunctionURLResponse` to avoid importing the AWS Lambda Events library. It is the first handler to be event-specific. I don't think the runtime should introduce event specific code. - The handler only works when Lambda functions are exposed through Function URLs. Streaming functions can also be invoke by API or CLI. - The handler hides `FunctionURLRequest` details (HTTP headers, query parameters, etc.) from developers Developers were unaware they were trading flexibility for convenience The lack of clear documentation about these limitations led to incorrect usage patterns and frustrated developers who needed full request control or were using other invocation methods. **Modifications:** - Removed the Streaming+Codable API from the library - Moved the Streaming+Codable code to an example - Added prominent warning section in the example README explaining the limitations - Clarified when to use Streaming+Codable vs ByteBuffer approaches - Added decision rule framework to help developers choose the right approach **Result:** The only API provided by the library to use Streaming Lambda functions is exposing the raw `ByteBuffer` as input, there is no more `Codable` handler for Streaming functions available in the API. I kept the `Streaming+Codable` code an example. After this change, developers have clear guidance on when to use each streaming approach: - Use streaming codable for Function URL + JSON payload + no request details needed - Use ByteBuffer StreamingLambdaHandler for full control, other invocation methods, or request metadata access This prevents misuse of the API and sets proper expectations about the handler's capabilities and limitations, leading to better developer experience and fewer integration issues.
6.5 KiB
This directory contains example code for Lambda functions.
Pre-requisites
-
Ensure you have the Swift 6.x toolchain installed. You can install Swift toolchains from Swift.org
-
When developing on macOS, be sure you use macOS 15 (Sequoia) or a more recent macOS version.
-
To build and archive your Lambda functions, you need to install docker.
-
To deploy your Lambda functions and invoke them, you must have an AWS account and install and configure the
awscommand line. -
Some examples are using AWS SAM. Install the SAM CLI before deploying these examples.
-
Some examples are using the AWS CDK. Install the CDK CLI before deploying these examples.
Examples
-
API Gateway: an HTTPS REST API with Amazon API Gateway and a Lambda function as backend (requires AWS SAM).
-
API Gateway with Lambda Authorizer: an HTTPS REST API with Amazon API Gateway protected by a Lambda authorizer (requires AWS SAM).
-
BackgroundTasks: a Lambda function that continues to run background tasks after having sent the response (requires AWS CLI).
-
CDK: a simple example of an AWS Lambda function invoked through an Amazon API Gateway and deployed with the Cloud Development Kit (CDK).
-
HelloJSON: a Lambda function that accepts JSON as an input parameter and responds with a JSON output (requires AWS CLI).
-
HelloWorld: a simple Lambda function (requires AWS CLI).
-
Hummingbird: a Lambda function using the Hummingbird web framework with API Gateway integration (requires AWS SAM).
-
S3EventNotifier: a Lambda function that receives object-upload notifications from an Amazon S3 bucket.
-
S3_AWSSDK: a Lambda function that uses the AWS SDK for Swift to invoke an Amazon S3 API (requires AWS SAM).
-
S3_Soto: a Lambda function that uses Soto to invoke an Amazon S3 API (requires AWS SAM).
-
Streaming: create a Lambda function exposed as an URL. The Lambda function streams its response over time. (requires AWS SAM).
-
Streaming+Codable: a Lambda function that combines JSON input decoding with response streaming capabilities, demonstrating a streaming codable interface (requires AWS SAM or the AWS CLI).
-
Testing: a test suite for Lambda functions.
AWS Credentials and Signature
This section is a short tutorial on the AWS Signature protocol and the AWS credentials.
What is AWS SigV4?
AWS SigV4, short for "Signature Version 4," is a protocol AWS uses to authenticate and secure requests. When you, as a developer, send a request to an AWS service, AWS SigV4 makes sure the request is verified and hasn’t been tampered with. This is done through a digital signature, which is created by combining your request details with your secret AWS credentials. This signature tells AWS that the request is genuine and is coming from a user who has the right permissions.
How to Obtain AWS Access Keys and Session Tokens
To start making authenticated requests with AWS SigV4, you’ll need three main pieces of information:
-
Access Key ID: This is a unique identifier for your AWS account, IAM (Identity and Access Management) user, or federated user.
-
Secret Access Key: This is a secret code that only you and AWS know. It works together with your access key ID to sign requests.
-
Session Token (Optional): If you're using temporary security credentials, AWS will also provide a session token. This is usually required if you're using temporary access (e.g., through AWS STS, which provides short-lived, temporary credentials, or for federated users).
To obtain these keys, you need an AWS account:
-
Sign up or Log in to AWS Console: Go to the AWS Management Console, log in, or create an AWS account if you don’t have one.
-
Create IAM User: In the console, go to IAM (Identity and Access Management) and create a new user. Ensure you set permissions that match what the user will need for your application (e.g., permissions to access specific AWS services, such as AWS Lambda).
-
Generate Access Key and Secret Access Key: In the IAM user credentials section, find the option to generate an "Access Key" and "Secret Access Key." Save these securely! You’ll need them to authenticate your requests.
-
(Optional) Generate Temporary Security Credentials: If you’re using temporary credentials (which are more secure for short-term access), use AWS Security Token Service (STS). You can call the
GetSessionTokenorAssumeRoleAPI to generate temporary credentials, including a session token.
With these in hand, you can use AWS SigV4 to securely sign your requests and interact with AWS services from your Swift app.