Clojurians Log v2

one thing I'd like to experiment with Lambdas, but haven't gotten around to, would be to have a setup similar to https://docs.serverless-stack.com/live-lambda-development, but not stream events from the env into local machine, but to establish nrepl connections, probably via websocket so once the Lambda process starts, it would connect to internal api gateway via websocket, where it can accept nrepl commands

I know the Lambda process has small lifetime, but 15min max is more than it used to be (like 5min max some time ago :))

just a toy idea, to see what it would be like

also, don't know if nrepl protocol allows multiple responses, from multiple instances :)

Implementing SST on top of holy-lambda is easy. I’m thinking what would you like to do with REPL on AWS?

heh, don't know exactly :D

bring the kind of repl that you normally have closer to Lambda, see if having that would spawn new ideas, since Lambda has some limitations, but good scaling ability

maybe I'm a bit of repl maniac :)

babashka even has nrepl 🤔

In my opinion it should be simple. 1. No WebSocket. Just simple stub lambda which takes the full event and publish it to sqs. 2. On holy lambda side there will be a separate command to publish the test stack. (Only nodejs, java, babashka runtime supported). After publication ARN is stored at .holy-lambda/test-stack-arn 3. You simply connect to nrepl, load holy-lambda.test-stack and call one of the functions • subscribe-with-pass - automatically passes event to corresponding handler subscribe - provide your own handler • Unsubscribe • get-one - get only one event

We can have another sqs to which we can push

And receive the output

Hum, was thinking on running arbitrary nrepl commands in the lambda process, allowing to broadcast a command to be run in multiple processes, maybe specify concurrency level. SQS allows one process to handle a single message, should then submit multiple sqs messages for processing.

was thinking that is there too many sqs queues afloat, but hmm, might need to deal with same processing with websockets anyway, so maybe input and output queues only

I guess I was wondering about the fanout