This is amazing. Congratulations! I've been thinking along similar lines and so happy this exists.
Have you considered extracting the lambda portion into a lambda extension so that you can deploy this as part of any cdk/cloudformation stack or standalone lambda and toggle on/off local debugging based on some registration in dynamo (e.g. store a predicate applied to the event and proxy to local if the predicate evaluates true)? This would allow something like this to be hugely useful in mitigating outages.
I didn't catch it in the repo yet but I'd you're proxying local AWS calls through the lambda to allow quickly catching IAM and security group/routing issues, that would be incredible.
Happy to help with this stuff and will definitely be a user!
I hadn't thought of using something like this for mitigating outages. Do you mind elaborating on that a bit more?
Currently there isn't a simple way to switch off the debug mode. So if `sst start` deploys the Lambda with the debug mode, `sst deploy` will disable it by putting the original Lambda back. But your idea of switching it on and off should work!
For the IAM portion, we are don't use the IAM credentials of the local machine while executing the Lambda. We use the credentials of the original Lambda. This allows for testing against the right credentials.
Appreciate the feedback! If you've have any questions or are curious about the internals, I'd love to hear from you jay@anoma.ly
Sorry, more investigation prior to mitigation than mitigation. I think moving the lambda aspects of sst to a lambda extension would allow for a workflow like this:
1. Find production issues
2. Replicate production issues in user facing tools
3. Run a local `sst start <fn> --filter '.userId == 'my-user-id'` to have remote <fn> connect to my local for any requests that match `evt.userId == 'my-user-id'`
4. Replicate issue and debug with the request sent to this particular lambda, potentially many calls away from the user action
5. Patch and deploy.
Being able to debug in situ would be fairly incredible in a complex application.
None of that is meant to take away at all from what you've built. What you have here is really awesome and I'm excited to use it.
Have you considered extracting the lambda portion into a lambda extension so that you can deploy this as part of any cdk/cloudformation stack or standalone lambda and toggle on/off local debugging based on some registration in dynamo (e.g. store a predicate applied to the event and proxy to local if the predicate evaluates true)? This would allow something like this to be hugely useful in mitigating outages.
I didn't catch it in the repo yet but I'd you're proxying local AWS calls through the lambda to allow quickly catching IAM and security group/routing issues, that would be incredible.
Happy to help with this stuff and will definitely be a user!