Wow, that is exactly what we are making. I posted elsewhere in this thread but SST (https://github.com/serverless-stack/serverless-stack) lets you work on your Lambda functions live without having to mock AWS services locally.
Yeah I wouldn't go down the local stack path. IMHO, you should develop/test against real AWS services, and it falls on the tooling to make that experience fast/smooth.
Think of it like your Lambda functions are Live Reloaded as you make changes to your code. You don't need to mock AWS services locally, and you don't have to wait for CloudFormation to deploy your changes.
It's quite limiting on:
1. It only mocks API Gateway, and not accurately (ie. IAM permissions). You also need to use a bunch of other similar plugins to mock DynamoDB, SNS, SQS, etc.
2. You need to change your code (wrapping your aws-sdk to connect to localhost) to use these mocking plugins.
I often see ppl adopt one of two development patterns:
1. Locally mock all the services that your Lambda function uses. Like API Gateway, SNS, SQS, etc. This is hard to do. If you are using a tool that mocks a specific service (like API Gateway), you won't be able to test a Lambda that's invoked by a different service (like SNS). On the other hand a service like LocalStack, that tries to mock a whole suite of services, is slow and the mocked services can be out of date.
2. Or, you'll need to deploy your changes to test them. Each deployment can take at least a minute. And repeatedly deploying to test a change really slows down the feedback loop.
SST lets you develop your Lambda functions locally while connecting to others AWS services without needing to mock them locally. Behind the scene, the lambda requests are streamed to ur local, runs ur local function, response streamed back to Lambda. So you can iterate on ur function code without redeploying.
Had I found that years ago, I would have saved SO MANY headaches. I've implemented local debugging (hell, and doesn't actually replicate AWS). I've followed the CloudWatch logs, just like you, painful.
The SST local debugging with lambda is the best way forward. Deploying micro services on seed.run is also the way forward.
Hey, thanks for the link. It does look quite good - there was another comment where someone had a home-brewed set up that did something fairly similar.
Frank here from Seed. Just wanted to add that when you have a monolithic Lambda, multiple routes would share a CloudWatch log group, metric, and share a common node in x-ray. On the flip side, the advantage of having separate Lambda functions handling each route lets you leverage other AWS services better.
Here’s a short demo (https://youtu.be/hnTSTm5n11g)
I'd love for you to give it a try.