Imagine a compiler like chrome v8 engine which analyzes code on runtime and figures out which code path are more resource intensive and manage them. So what if same way compiler notices that certain code path executions take longer and start spreading them on other threads/cores/machines like kubernetes and orchestrating all of it behind the scene.
So you as a developer don't worry about that.
Let's take javascript
suppose every promised function had potential to be it's own serverless function, depending on resources usage, compiler can either run it on main thread or delegate to cluster.
let data = await getData();// compiler sees getData takes time and is put its own serverless function or something.
I feel this could be ground breaking. Automatic app scaling based on runtime analysis of code paths.
We could have do this right now, with external a library in js using something like this...
let data = await SF(getData(123)); //SF spawns new serverless function based on body of SF...
but it'd be better if it was implemented at language level. I'd like it if chrome team did it.
CDK (Cloud Development Kit) lets you orchestrate creation of lambdas with TypeScript code, so in theory you can have one codebase with a file describing what methods to export and it’d provide a method to call the lambda with await. See example here: https://github.com/aws-samples/aws-cdk-examples/blob/master/...
And bash, because it does exactly this — spawns a process with an input for almost any work. If you think of the most basic bash commands, say “git ... | grep ... | sort ... | tee” you end up with 4 concurrent processes piping data from left to right. Compose bash functions instead of long lines and you got yourself a maintainable codebase. I understand this scales to one instance size, but you could throw 64 cores at the problem, writing many processes to work together, utilising all CPUs. Thinking outside of bash — using “await spawn()” in node you could start a new node process with execution of another function, just matter how you export them, or if a decorator can stringify the function.
Alternatively, you can create single lambda that calls any function in the codebase. Your decorator can register the function, and when lambda runs, it checks all registered functions and calls the one matching the request.path. For something more advanced you can build custom runtime which defines exactly what lambda executes: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom...
@spawn //makes this a lambda
function fn() ... {}
@queue //makes this a queued function sqs or similar
function fn() ... {}