Yeah `sls invoke local` works well for testing individual functions where you are mocking the specific inputs or triggers. But there are a couple of cases where it can become hard to use. For example, if you want to test a Lambda function that's invoked by an API that needs authentication. Or if Lambda A publishes to an SNS topic that invokes Lambda B and you want to test the entire flow.
To fix this SST will deploy your entire stack, and let you trigger the workflow live. So you can hit the endpoint just as your frontend would, or trigger the entire SNS workflow. Except all the Lambda function invocations will be streamed to your local machine and the responses will be sent back.
This approach allows you to get the best of both worlds. The speed on an `sls invoke local`, without having to mock anything.
> This approach allows you to get the best of both worlds. The speed on an `sls invoke local`, without having to mock anything.
But I have to deploy stub functions and have a different deployment model for prod. :) So there are definitely tradeoffs.
I like this idea and will certainly try it out!
What I was really hoping for is someone who could figure out a way to launch a terminal in Lambda so that I can modify my functions in place and view the logs in place, and then when I'm done, save my work to git, like I used to be able to do when I had a fleet of servers and could just log onto one of them in prod and muck around with logs (and yes I know this is a bad idea but it's also how things get done quickly).
While this doesn't quite do the edit in place and I wouldn't recommend running this for prod with live traffic; we use it to run some scripts against prod. You get an environment where you can make changes quickly as opposed to having to deploy your function to run them.
To fix this SST will deploy your entire stack, and let you trigger the workflow live. So you can hit the endpoint just as your frontend would, or trigger the entire SNS workflow. Except all the Lambda function invocations will be streamed to your local machine and the responses will be sent back.
This approach allows you to get the best of both worlds. The speed on an `sls invoke local`, without having to mock anything.