latacora / lamed Goto Github PK

The easiest way to deploy a custom runtime would be to compile the runtime code into a layer that will call the lambda. A user of lamed could then just add the lamed runtime as a lambda layer without any changes to their code. The aws bash custom runtime example ends with this setup.

The tricky part of this is how to call functions between two native-image executables.

Implementation tasks:

• figure out how/if it's possible for a GraalVM native image executable call a function in another native image executable
• make lamed read and use the _HANDLER and other env vars to call the client function
• move bootstrap to lamed
• example lambda deployment

The awslabs C++ and rust runtimes may or may not be useful examples.

It's faster to prototype code using the java runtime, and the standard way to write a lambda handler in clojure is to implement RequestStreamHandler interface with the following signature:

(defn -handleRequest
  [this in-stream out-stream context]
...

Lamed should have a method that takes a method with the above signature and appropriately pipes input/output data

Clojure has a practice of data everywhere, even in errors, see ex-info/ex-data.

https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html suggests that errors (both init errors and invocation errors) take an errorMessage and an errorType. That's pretty close to what we have, but the ideal behavior is probably:

• If something has ex-data, return the message (toString?) and data
• If something doesn't, return its type and toString

Lamed calls the Lambda Runtime API over HTTP to figure out what to do next, so even if your app doesn't use HTTP you need that native-image flag.

See also latacora/lamed-sample-app#1

Add a basic lambda function w/ graalvm integration and also write up a doc describing what a user of lamed needs to do to generate a graalvm lambda build