Holy lambda is a micro framework which adds support for running Clojure on the AWS Lambda and might be used with arbitrary AWS Lambda deployment tool. Holy lambda provides very convinient environment compared to other tools such as uswitch/lambada or babashka-lambda via simple, but powerful
Makefile recipes eg. deployment is as easy as running
make make-bucket deploy (for native lambda
make make-bucket native-deploy).
Holy lambda supports
- ring request, response model
- async handlers
Prior work towards targeting Java runtime was done by uswitch/lambada, but lacked being convienient. Holy lambda in the other hand is very convinient and does things which lambada lacked:
- full class identifier is created during macroexpansion of
- request is automatically slurped and converted to a map
- response mimics Ring therefore you don't have to write to
- supports interceptors
- converts ctx
I've started experimenting with native runtime around May 2019 inspired by @hjhamala blog post. At that time Clojure community just started experimenting with GraalVM, and there was not such great tools as babashka, therefore holy-lambda is not babashka based. There are some benefits of not using babashka and some tradeoffs which have to be understood before taking a right decision.
- lambdas will be faster in general, because code is not interpreted (benchmarks in-progress)
- use any GraalVM Clojure compatible library. Not only one from limited pool of babashkas pods
- target both Java & native runtime
- mix GraalVM supported languages freely (polyglot)
- use Profile-Guided Optimizations on GraalVM EE PGO
- you have to generate native-configurations for GraalVM (automated by running
- GraalVM compilation is long - for development use Java runtime with
sam invoke or
- adding and using new libary is not always easy when compiling to native, some extra know-how about GraalVM is needed
If you're not interested in trying holy-lambda out then you can check babashka runtime :) babashka-lambda.