Requirements for Live Development Environment for HL

[FieryCod]

How we can make Live Lambda Development environment in Clojure way?

I did some hammock time and was puzzled by the idea for some months. After seeing today's tweet from @borkdude about AWS Lambda "eval" I was inspired to write my thoughts about what perfect live-development environment for Clojure would mean for me.

Goals

• A fast feedback loop (no more than 100ms),
• Having running nREPL locally with the ability to access remote AWS resources,
• nREPL that is running as long as I only want,
• Support for JVM & CLJS & Nbb & Babashka
• a dashboard with the following features:
  • see all the requests that lambda was invoked with sorted by time,
  • I want to be able to click on the particular request and see:
    • logs,
    • event,
    • result,
  • I want to be able to create a new event by "cloning" the existing one and changing its properties,
  • I want to query either particular request or query for the information in all requests (not required, just nice to have)
    • logs,
    • event,
    • result

Non Goals

• real deployment,
• partial deployment (see AWS SAM Accelerate. Still, it takes a few seconds to propagate,
• state update or state persisting

How would the user interact with the system?

1. A user spans a new nREPL connection e.g. bb --nrepl-server.

2. The user connects to a running repl.

3. If this is the first time user is trying to use a system, it's first required to deploy it to AWS (or if the infrastructure changes)

   The deployed system in /unified-live-development/welcome presents all the necessary information for the user to connect to the system:

       Hello dear user. Welcome to in unified-live-development system version x.y.z made by Clojure AWS Domination Team 
       Follow the instructions below or head to documentation <link>:
    
       <instructions>
       Available URLS:
       - Welcome Screen (/unified-live-development/welcome)
       - Dashboard (/unified-live-development/dashboard)
       - Socket connection (/unified-live-development/repl)
   
   

4. User connects to socket, that way the events from Lambda flows to local environment.

5. On the local environment on each remote lambda invocation the mounted handler is invoked with the payload.

6. User can remount the handlers, or manually get one of the remote events from the history.

Technical details
Our system consist of:

• DynamoDB
• Websocket (dunno why sls introduced S3 if Lambda has a hard limit on size of the payload :OOOO)

1. We will need a DynamoDB for storage, and HL native-runtime + arm64 for maximum speed and low cost, also my custom runtime doesn't need to have the event to handler mapping and can proxy everything :D,
2. We will have to parse SAM template or any other yaml (i don't want to play with terraform, or AWS CDK yet, AWS CDK and terraform can still use the SAM templates. In parsed yaml we replace the CodeUri definitions with our stub function (stub function is the same for all the available AWS services integrations, we don't care with what the system is used), save it in hidden directory like .holy-lambda and deploy.
3. Our stub function works like this:
   • Upon the event stub sends the payload to a DynamoDB (invocation id with our unique identifier) (if not yet saved) and transmits the event to the users connected to our Websocket API,
   • The user is already connected via the nREPL, and handlers are mounted. Handler is invoked with the payload. Our mounting code listens for stderr/stdout and upon completion sends it to dynamodb. Our mounting code waits for the response and sends it to dynamodb and via websocket to our websocket API that responds to stub lambda, that returns the result.

Trade-offs

• AWS Lambda on the private subnets, or the ones requiring the access to resources behind private subnet would not be allowed to use it easily.
  A bastion in the same VPC would have to be created, then:
  1. aws ssm start-session --target <BASTION_INSTANCE_ID>
  2. Connect to the running socket API
  3. In another terminal:

  aws ssm start-session --target <BASTION_INSTANCE_ID> --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["<PORT>"], "localPortNumber":["<PORT>"]}'
  

[viesti]

Thinking that we could expand SST/Live Lambda Development for Clojure, by making support that does the invoke in a locally running application, where you have a REPL open. This could bring the live dev experience into Clojure land. I haven't yet tried out SST so don't know the effort required, but would probably be worth to survey this option.

One idea that came into my mind is that what if the SST proxy lambda would have nbb included. Then we could use this to send code for evaluation via the SST websocket proxy. Based on the DynamoDB table that contains Lambda processes that have been registered, we could even pick the one with most lifetime left for evalling.

[vharmain]

@viesti what is SST you're referring to?

[FieryCod]

This is SST: https://docs.serverless-stack.com/live-lambda-development