4 ms·
LocalStack is cool, but don't forget that you always have an alternative to build mock infrastructure in front of your AWS deps. Don't call S3 deps directly - i
by mmastrac 4y ago
LocalStack is cool, but don't forget that you always have an alternative to build mock infrastructure in front of your AWS deps. Don't call S3 deps directly - implement a higher abstraction using only the APIs you actually call and back it with your local filesystem (for example).
It's not a _lot_ of work, and making your dev/prod differences more explicit can make debugging much easier.
- lololol0l 4y ago
- zdragnar 4y agoMocks and adaptations such as localstack and serverless can be equally leaky or incomplete. You don't really know until you hit the real stage if what you've got is ready.
- alphakilo 4y agoanecdotal evidence by default they have it so S3 requests with wrong headers are still sent I didn't know this and one day I changed the send header but not receive header Turned out the cache-control was wrong when uploading an image to a presigned url, but this was never caught until it hit staging env since local tests and CI/CD tests showed a pass
- rmbyrro 4y agoI've had issues with LocalStack in the past. Decided it wasn't worth the savings compared to running against the real AWS services.
- silv-io 4y agoDepending on how far in the past that was it might be worth it to revisit. Especially in the last year lots of things have changed.
- mplewis 4y ago"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
- Havoc 4y agoOr just throw minio on a box somewhere
- rmbyrro 4y agoIt's work unrelated to your project, doesn't add any value. Besides, it's reinventing the wheel. And it's certainly cheaper to run local dev/tests against the real AWS S3 infra than paying the time to mock it with your local filesystem...
- mdaniel 4y agoI disagree about the "doesn't add value" part when talking about introducing an abstraction over the AWS sdk: with mocks, it allows one to simulate failures, hung connections, and reproduce bugs without trying to contort an actual AWS account into the bad configuration that one might encounter in the real world Your assertion about "cheaper" is also only true if one remembers to tear down all those resources when finished testing against them