Clojurians Log v2

Our team has a couple of lambdas in a Polylith repo. Unfortunately it is a private one, that I cannot share here. We have a project containing a deps.edn with depencencies and aliases. A base with a namespace that contains the lambda entry point. The "api" of the lambda. The base consumes components with functionality used by the lambda, just as in any other Polylith project. To build the lambda, we use depstar and have a "compile" (or did we name it "jar"?) alias that AOT-compiles the code and builds a jar file. That file is the one we deploy to AWS. The jar-file can be manually deployed, or (as we do) with AWS CDK ("infrastructure as code"). Hope this helps!

@furkan3ayraktar has several years of experience of working with AWS lambdas + Polylith. He could be a good candidate to explaining this.

Thanks!

I have a very similar setup to David. I used uswitch/lambada library to expose the lambda handler in the base. Then, the project configuration (`deps.edn`) decides which components go together with the lambda base. I’m using juxt/pack.alpha to generate AOT compiled jars, but I think depstar could be a better choice. I have this naming convention for the lambdas in my workspace where if the project is named, e.g. xxxx, then my Lambda base is named xxxx-lambda. Then if I have a REST api project named yyyy, then I would name its base as yyyy-rest-api. This helps me easily see bases that expose different API types.

thanks @furkan3ayraktar!