Motivation:
Provide the flexibility for custom initialization of the HandlerType as this will often be required by higher level frameworks.
Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Handler Type of Handler Provider
* Add and update tests
Originally suggested and coded by @tachyonics in https://github.com/swift-server/swift-aws-lambda-runtime/pull/308
motivation: define stable API in preperation 1.0 release
changes:
* require swift 5.7, remove redundant backwards compatibility code
* make LambdaHandler, EventLoopLambdaHandler, and ByteBufferLambdaHandler disjointed protocols to reduce API surface area
* create coding wrappers for LambdaHandler and EventLoopLambdaHandler to provide bridge to ByteBufferLambdaHandler
* reuse output ByteBuffer to reduce allocations
* add new SimpleLambdaHandler with no-op initializer for simple lambda use cases
* update callsites and tests
* update examples
Co-authored-by: Yim Lee <yim_lee@apple.com>
Co-authored-by: Fabian Fett <fabianfett@apple.com>
motivation: adopt to sendable requirments in swift 5.6
changes:
* define sendable shims for protocols and structs that may be used in async context
* adjust tests
* add a test to make sure no warning are emitted
motivation: make it simpler to register shutdown hooks
changes:
* introduce Terminator helper that allow registering and de-registaring shutdown handlers
* expose the new terminator hanler on the InitializationContext and deprecate ShutdownContext
* deprecate the Handler::shutdown protocol requirment
* update the runtime code to use the new terminator instead of calling shutdown on the handler
* add and adjust tests
If we want to minimize allocations for every invocation, we need to look at types that currently allocate. Currently we use a String to hold the request id. However since the request id is a uuid, that string is 36 characters long. This is way above the 15 character string allocation threshold. The go to type in this case would be `UUID`. However `UUID` is in Foundation and we want to keep the lambda runtime Foundation free.
This pr introduces a LambdaRequestID to represent a uuid. One nice side effect of having our own uuid case is: We can make writing the uuid-string to a ByteBuffer allocation free (since no intermediate translation to a string is needed first).
### Motivation:
In the coming weeks, we want to restructure the LambdaRuntime internals in such a way, that we allocate a lot less resources per invocation. To accomplish this, we want to encode and decode the ControlPlaneAPI requests directly from their semantic value. For this reason, we need a specialized ControlPlaneRequest and ControlPlaneResponse type that we can encode from and decode into.
### Modifications:
- Add `ControlPlaneRequest`, `ControlPlaneResponse`
- Move `Invocation` and `ErrorResponse` into same file as `ControlPlaneRequest`
- Remove `Lambda` namespace around `Invocation`
Adopt Swift Concurrency adoption guidelines for Swift Server Libraries (swift-server/guides#70).
- Use #if compiler(>=5.5) && canImport(_Concurrency) to judge if Concurrency is available
- Some clean up
* take advantage of @main where possible
* move the top level Sample code to the examples subdirectory
* extract a few examples form the "LambdaFunctions" directory (which is really a deployment demo) and move them to the top level Examples directory
* rename "LambdaFunctions" examples as "Deployments" to make their intent clearer
* add a sample that demonstrates how to test a lambda now that SwiftPM can test executables directly
* update the test-sample docker setup to build & test th new samples
* fix a few typos and In/Out typealias left overs
* remove LinuxMain since its no longer required
motivation: with async/await, no need in closure based APIs
changes:
* Drop closure APIs
* Rename AsyncLambdaHandler -> LambdaHandler
* Removed unnecassary public acls from tests
- Add an `AsyncLambdaHandler`. Will be renamed to `LambdaHandler` as soon as we drop the current callback based `LambdaHandler`.
- The default way to use an `AsyncLambdaHandler` is to use `@main` to execute it. Don't use `Lambda.run` for it. We wan't to remove `Lambda.run` for 1.0.
Co-authored-by: tomer doron <tomerd@apple.com>
Modifications:
- Replace `HTTPHandler` with `NIOHTTPClientResponseAggregator`, to fix a CoW issue. This increases performance.
- Ensure that we only use one `EventLoop` in tests.
- Use `syncOperations` to setup the `HTTPClient`.
motivation: more correct Xray TraceID
changes:
* add AmazonHeaders::generateXRayTraceID
* Generate correct trace ID in LocalLambda Server
* Generate correct trace ID in LambdaRuntimeClientTest
* allow the users of client to provide headers
* add initialization error header
* add error header to failed invocations
* fix external setting of ip and port via config
* add tests
motivation: in more complex initialization scearios you may want access to a logger or other utilities
changes:
* introduce new InitializationContext type that could be extended in the future without breaking the API in semantic-major way
* instead of passing in EventLoop to the handler factory, pass in a context that includes a Logger, an EventLoop and a ByteBufferAllocator
* fix a bug where we dont hop back to the event loop when coming back from the handler
* adjust tests to the new signature
motivation: allow end to end testing locally
changes:
* add a Lambda+LocalServer which exposes Lambda.withLocalServer available only in DEBUG mode
* local server can receive POST requests with payloads on a configurable endpoint and and send them to the Lambda
* move Lifecycle completely into EventLoop
* remove all locks since running in one EventLoop
* Use UUID for requestId
Co-authored-by: tom doron <tomer@apple.com>
Sébastien Stormacq
Alessio BurattiandSébastien Stormacq
tomer doron
Stefan Nienhuis
YR Chen
tomer doron
Fabian Fettandtomer doron
pokryfka
Ro-M