Native backend/runtime is GraalVM native-image compiled version of AWS Custom Runtime. Native runtime is entirely written in Clojure and upon hl:native:executable
packed with the user code.
The output artifact of this operation is zip
which can be deployed with any of the available deployment tools.
Sure! HL doesn't stop you from using any of above deployment tools. All you need is the knowledge how to build deployable artifacts, that you can reference in your deployment descriptor.
Deployable artifact coordinate according to backend
Clojure - > .holy-lambda/build/output.jar
Build command
bb hl:compile
Native -> .holy-lambda/build/latest.zip
Build command
bb hl:compile && bb hl:native:executable
Content of latest.zip
bootstrap
- a script that executes the initializes the runtime and executes the binaryoutput
- native compiled Clojure user code + Custom runtimenative-deps
- dependencies of the applicationBabashka -> src
(Application sources provided as is)
Babashka backend is provided as a serverless layer which you have to deploy manually and reference it's ARN in deployment descriptor.
src
as the CodeUri
of your application.provided
and reference ARN of the layer in layers
option..holy-lambda/bb-clj-deps
..holy-lambda/pods
.Nope! Native, Babashka and Java runtimes are synchronous, but handlers can be asynchronous for convenience and return either:
- `Channel<Map|String|ByteArray|nil>`
- `Future<Map|String|ByteArray|nil>`
- `Promise<Map|String|ByteArray|nil>`
Still though the runtime will wait for the result of asynchronous handler, before taking a new task to process. Scaling lambdas should be achieved via concurrency option. More info here
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close