Apply recommendations in code and documentation
- [CI] restrict permissions to read-all instead of the default write-all
- All examples README.md : add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
- Swift docc documentation: add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
All the examples using SAM have a default Lambda runtime environment
memory size of 512Mb.
Lambda functions run in a microVM defined by its memory size. The memory
size influences the CPU power.
(see
https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html)
Increasing memory size increases runtime performance but also increase
costs.
As most of our examples are very simple and small functions, 512Mb
memory is not required. This PR reduces Lambda runtime execution
environment to 128Mb to reduce AWS costs.
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
In preparation for the 2.0.0 GA release,
- Update `.swift-version`, `Package.swift` and all examples'
`package.swift` to Swift 6.2
- Update all references to `2.0.0-beta.3` to `2.0.0`. This includes the
doc and readme, but also the dependencies in the examples
`Package.swift`. This will temporary break the build of the examples,
until we tag v2.0.0. Note the CI will not be affected as its consumes
the local version of the library
- [CI] Use Swift-6.2-noble for all testing tasks
- Reinstate the script to generate the contributors list and update the
list
This new example project show four testing strategies for Swift Lambda
function
- Unit testing the business logic (not specific to Swift Lambda)
- Integration testing the handler method
- Local invocation with the Swift Lambda Runtime
- Local invocation with SAM
**[IMPORTANT]**
To allow testing the handler, I had to change visibility of a method in
the Runtime project. This method is clearly marked for testing only, so
it should not be a problem. Happy to read feedback and discuss however.
motivation: examples can be confusing since they use relative path to the library for CI purposes
changes:
* update examples to use the library URL, expect when env variable is set for CI purposes
* rename docker compose job to test-examples since it is more accurate
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>
* 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
Sébastien Stormacq
Franz Busch
tomer doron
Fabian Fett
tomer doron