The local lambda spins up a new node process for e...
# sst
t
The local lambda spins up a new node process for every invocation
r
Ah, that explains it then
f
Yeah, we are going to keep the node process around for subsequent invocations https://github.com/serverless-stack/serverless-stack/issues/504
t
I don't have a ton of context so maybe this makes no sense but have you looked at using this: https://github.com/aws/aws-lambda-nodejs-runtime-interface-client
I was thinking potentially the dispatcher could have no language specific code and be passed in configuration for
{ build_command, watch_dir, runtime_command }
Then adding new languages would be creating configuration vs adding code but maybe my assumptions are too simplistic
f
Yeah, it seems
aws-lambda-nodejs-runtime-interface-client
can replace lambci’s
boostrap.js
we currently use. I will play around with it when I get to work on this (just added to the issue’s TODO).
We should standardize the watch/build/runtime for all the languages. I’m going to start refactoring the code toward it when we add C# support (the next one on the list based on user request).
t
sweet that's gonna be cool, have some funky languages I want to try in a lambda
r
Fortran 77 for the win
f
NodeJS is a bit special as we try to optimize its performance, so we do things like running
esbuild
programmatically instead of thru command line; only watching files
esbuild
parsed instead of an entire folder; etc. But for other languages, we can standardize.
t
Ah that makes sense. In the node case could the build command be
sst/optimized_node_builder.js
eh I guess it might be too hard to abstract it well
f
Yeah let’s see when I get to work on this.. I try to abstract stuff when it becomes a burden for implementing something new lol