This makes perfect sense. The closest what comes to my mind is CDK and bash. CDK (Cloud Development Kit) lets you orchestrate creation of lambdas with TypeScri

This makes perfect sense. The closest what comes to my mind is CDK and bash. 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/typescript/lambda-api-ci/lib/lambda-api-stack.ts 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.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom...