I abandoned Express when I moved to Lambda. Express was just handing the routing, which I didn't need anymore with Lambda, API Gateway handles that now. My front-end also calls most Lambdas directly using Cognito for auth.
The only time I have problems with Lambdas growing too large is when I try to include a really big payload that includes something like Chrome for headless screenshots, or FFMPEG, or other large binary programs. But for normal Lambda functions I don't have any size issues. Recently when trying to get headless Chrome working in Lambda, I had to boot up EC2 running AWS Linux, and create a .zip file there with library files that were missing in Lambda, then .zip up everything and upload to S3 and then import the .zip into Lambda. After this, I can modify my .js files locally and have my toolchain upload the changes to Lambda to update the Lambda. But this time the payload was too large for importing into a Lambda, and too big for a Lambda layer. The solution was saving the .zip file with Chrome in it to an S3 bucket, and when the Lambda machine starts up, it first downloads the .zip file to /tmp, unzips it, and now the Lambda has the Chrome binaries in the /tmp folder. This bypasses the size limits associated with Lambda. It's rare that I need to do this, and it's not fun, but there are always going to be some edge cases like this with Lambda and getting large architecture specific binaries running in Lambda.
I actually put many different functions into a single Lambda, and I call the Lambda with a specific action parameter to perform a specific function.
Local development... when I create a Lambda function I may add some functionality so I can also run it on the command line if I'm still early in developing a complex function. But most of the time I just use my self-built toolchain which watches my local code for changes, then creates/updates the Lambda in AWS, which takes about 2 to 5 seconds typically. Then I test the code as it runs inside AWS. If I didn't have internet access, then it's impossible to develop in this way, but that's almost never the case.
The only time I have problems with Lambdas growing too large is when I try to include a really big payload that includes something like Chrome for headless screenshots, or FFMPEG, or other large binary programs. But for normal Lambda functions I don't have any size issues. Recently when trying to get headless Chrome working in Lambda, I had to boot up EC2 running AWS Linux, and create a .zip file there with library files that were missing in Lambda, then .zip up everything and upload to S3 and then import the .zip into Lambda. After this, I can modify my .js files locally and have my toolchain upload the changes to Lambda to update the Lambda. But this time the payload was too large for importing into a Lambda, and too big for a Lambda layer. The solution was saving the .zip file with Chrome in it to an S3 bucket, and when the Lambda machine starts up, it first downloads the .zip file to /tmp, unzips it, and now the Lambda has the Chrome binaries in the /tmp folder. This bypasses the size limits associated with Lambda. It's rare that I need to do this, and it's not fun, but there are always going to be some edge cases like this with Lambda and getting large architecture specific binaries running in Lambda.
I actually put many different functions into a single Lambda, and I call the Lambda with a specific action parameter to perform a specific function.
Local development... when I create a Lambda function I may add some functionality so I can also run it on the command line if I'm still early in developing a complex function. But most of the time I just use my self-built toolchain which watches my local code for changes, then creates/updates the Lambda in AWS, which takes about 2 to 5 seconds typically. Then I test the code as it runs inside AWS. If I didn't have internet access, then it's impossible to develop in this way, but that's almost never the case.