Add user-facing API for Streaming Lambda functions that receives JSON
events
### Motivation:
Streaming Lambda functions developed by developers had no choice but to
implement a handler that receives incoming data as a `ByteBuffer`. While
this is useful for low-level development, I assume most developers will
want to receive a JSON event to trigger their streaming Lambda function.
Going efficiently from a `ByteBuffer` to a Swift struct requires some
code implemented in the `JSON+ByteBuffer.swift` file of the librray. We
propose to further help developers by providing them with a new
`handler()` function that directly receives their `Decodable` type.
### Modifications:
This PR adds a public facing API (+ unit test + updated README) allowing
developers to write a handler method accepting any `Decodable` struct as
input.
```swift
import AWSLambdaRuntime
import NIOCore
// Define your input event structure
struct StreamingRequest: Decodable {
let count: Int
let message: String
let delayMs: Int?
}
// Use the new streaming handler with JSON decoding
let runtime = LambdaRuntime { (event: StreamingRequest, responseWriter, context: LambdaContext) in
context.logger.info("Received request to send \(event.count) messages")
// Stream the messages
for i in 1...event.count {
let response = "Message \(i)/\(event.count): \(event.message)\n"
try await responseWriter.write(ByteBuffer(string: response))
// Optional delay between messages
if let delay = event.delayMs, delay > 0 {
try await Task.sleep(for: .milliseconds(delay))
}
}
// Finish the stream
try await responseWriter.finish()
// Optional: Execute background work after response is sent
context.logger.info("Background work: processing completed")
}
try await runtime.run()
```
This interface provides:
- **Type-safe JSON input**: Automatic decoding of JSON events into Swift
structs
- **Streaming responses**: Full control over when and how to stream data
back to clients
- **Background work support**: Ability to execute code after the
response stream is finished
- **Familiar API**: Uses the same closure-based pattern as regular
Lambda handlers
Because streaming Lambda functions can be invoked either directly
through the API or through Lambda Function URL, this PR adds the
decoding logic to support both types, shielding developers from working
with Function URL requests and base64 encoding.
We understand these choice will have an impact on the raw performance
for event handling. Those advanced users that want to get the maximum
might use the existing `handler(_ event: ByteBuffer, writer:
LambaStreamingWriter)` function to implement their own custom decoding
logic.
This PR provides a balance between ease of use for 80% of the users vs
ultimate performance, without closing the door for the 20% who need it.
### Result:
Lambda function developers can now use arbitrary `Decodable` Swift
struct or Lambda events to trigger their streaming functions. 🎉
---------
Co-authored-by: Tim Condon <0xTim@users.noreply.github.com>
~~Attempt to fix CI~~
Remove usage of deprecated parameters on unit-test.
- explicitly enable tests on nightly 6.0
- explicitly enable tests on nightly next
- explicitly enable tests on nightly main
At the time of this writing, this resolves to
```
linux_6_0_container_image="swift:6.0-jammy"
linux_nightly_next_container_image="swiftlang/swift:nightly-6.1-jammy"
linux_nightly_main_container_image="swiftlang/swift:nightly-main-jammy"
```
---------
Co-authored-by: Fabian Fett <fabianfett@apple.com>
Resources are not included in the archive on Linux
https://github.com/swift-server/swift-aws-lambda-runtime/issues/505
In addition, the script that checks if the resources are correctly
included in an archive when building on Linux is not working.
It failed to detected missing resources.
This patch fix both the plugin and the CI script
When we include Traits, we changed the CI container from Swift 6.0
Amazon Linux to Swift 6.1 Nightly on Ubuntu.
This broke the CI because AWS SDK used in the `Examples/S3_AWSSDK`
example depends on `libssl-devel` which is not installed by default on
Jammy images.
This PR reverts back the container used to test all examples to an
Amazon Linux 2, but this time the 6.1-nightly version to allow to
compile the package traits.
This should address
https://github.com/swift-server/swift-aws-lambda-runtime/issues/494
Add `S3EventNotifier` example
### Motivation:
There is currently no example regarding an AWS event triggered lambda,
such as a lambda that gets invoked on an S3 object upload. I've had to
look for a while to figure out that the `AWSLambdaEvents` exists and
that it can be used for that (had to find out via a Java example! 😜) so
I think this could be useful and a somewhat common use case
### Modifications:
Added an example of a lambda that gets triggered when an object gets
uploaded to an S3 bucket.
I have not described how to set up the actual S3 event in AWS because I
figured if you needed such a lambda you'd know, but I can describe that
too in the README if needed
---------
Co-authored-by: Sébastien Stormacq <sebastien.stormacq@gmail.com>
When including resources in the package and packaging on Ubuntu,
`FileManager` throws a FilePermission error. The docker daemon runs as
root and files to be copied are owned by `root` while the archiver runs
as the current user (`ubuntu` on EC2 Ubuntu). The `FileManager` manages
to copy the files but throws an error after the copy. We suspect the
`FileManager` to perform some kind of operation after the copy and it
fails because of the `root` permission of the files.
See
https://github.com/swift-server/swift-aws-lambda-runtime/issues/449#issuecomment-2595978246
for a description of the problem.
This PR contains code to reproduce the problem, a very simple
workaround, and an integration test.
The workaround consists of
- trapping all errors
- verify if the error is the permission error (Code = 513)
- verify if the files have been copied or not
- if the two above conditions are met, ignore the error, otherwise
re-throw it
I would rather prefer a solution that solves the root cause rather than
just ignoring the error.
We're still investigating the root cause (see [this
thread](https://forums.swift.org/t/filemanager-copyitem-on-linux-fails-after-copying-the-files/77282)
on the Swift Forum and this issue on Swift Foundation
https://github.com/swiftlang/swift-foundation/issues/1125
Add an example of an APIGateway Lambda Authorizer
### Motivation:
Lambda Authorizers allow developers to write custom logic to validate
HTTP REST requests.
This example shows how to write a Lambda Authorizer in Swift and how to
configure an API Gateway to use a Lambda Authorizer.
This example use a SAM template to deploy the resources.
### Modifications:
- Add `Examples/APIGateway+LambdaAuthorizer` directory with the source
code, a `template.yaml`, and a `README` file.
- Add a reference to the new example in `Examples/README`
- Modify CI to build the new example
### Result:
There is a new example showing how to develop a Lambda authorizer in
Swift and how to attach it to an APIGateway with SAM
This adds a test in the `integration_test.yml` workflow to verify that
`libFoundation.so`, `libFoundationInternationalization.so`, and
`lib_FoundationICU.so` and not linked the the function binary.
This is a follow up from the work make by @t089 to ensure that we don't
accidentally link Foundation again in the future.
Remove Foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/pull/436
Add test in CI to ensure we don't link to foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/issues/402
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
* add aws sdk example
* add soto example
* use amazonlinux docker image instead of ubuntu
* dynamically add runtime dependency based on env var
* remove import of Foundation.ProcessInfo
* workaround https://github.com/actions/checkout/issues/1487
* Require Swift 6
* Apply formatter
* Disable 5.8, 5.9, and 5.10 checks
* Remove -warnings-as-errors for now
* Ensure plugin compiles in Swift 6 language mode