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 application
-
Babashka ->
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.
- Deploy the layer and get it's ARN.
- Reference
src
as theCodeUri
of your application. - Set runtime to
provided
and reference ARN of the layer inlayers
option. - Additional Clojure deps should be packed to a layer. Clojure deps are stored at:
.holy-lambda/bb-clj-deps
. - Additional babashka pods should be packed to a layer. Babashka pods are stored at
.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