Fork me on GitHub
#portkey
<
2021-04-23
>
viesti15:04:41

Humdeum, there's good amount of Lambda activity going on in #holy-lambda , so check it out if interested in packaging Lambdas 🙂

viesti15:04:39

got me thinking again of side loading code into a running Lambda process, kind of "nrepl", but via the aws infra, maybe putting repl artifacts into S3, or maybe even to ElasticCache/redis etc. hmm...

valtteri19:04:07

How about EFS?

viesti19:04:49

aa, that available for Lambdas now as well

viesti19:04:11

run a nrepl middleware in lambda, that connects to a "repl" api gateway via a websocket, then have another middleware on the dev machine, that connects to that same "repl" api gateway, which then tunnels nrepl commands to the lambda, results and printouts to local repl

viesti19:04:08

when the lambda times out, signal back to repl, to (optionally) create a new deployment

viesti19:04:41

a bit brainstorming here, the above related to jvm lambda probably

viesti19:04:52

repl that resets itself every now and then might require a bit different programming model that normally

viesti19:04:00

could keep log of commands to re-apply maybe, maybe stuff run in lambda not usually initiated from repl, but from event source outside, def:ing the lambda input for playing, even at the local repl, might be neat

viesti19:04:48

eh, somehow mixed a nrepl client with two nrepl servers :) (one local, one in lambda), have to think if that is actually a good idea or just a mishap :)

viesti19:04:36

say that one runs the project locally with a repl, does some initial build and deploys it, then we'd have a utility library that can talk to the remote lambda, kind of having a handle to it via a (nrepl) connection, be able to send forms to it to eval code and get results, maybe replay those form send to a lambda when the process recycless, humdum