Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have detailed knowledge of dynamodb. This code does not properly mimic the service exceptions, input validations, eventual consistency, or edge cases. I would not feel comfortable developing against ministack or running tests against it. A lot of these services also have free tiers, so the use cases are quite minimal.


Mostly I think its not about cost, it is about iteration speed and ability to run in CI environments fast.


If your CI DB is not 100% in parity with the real db -- you are setting yourself up for disaster. It is a false sense of security.

Same reason I wince when people say things like "we just use SQLite in tests, but our real db is mysql/psql/etc"

The test results have no merit if they are testing against a glorified mock.


You could have the fast tests that catch 99,9999% of the issues on feature branches and just run the real slow test before putting in prod.


You can have fast tests and slow. Having fast tests to make progress working on features is important.


Hello! The target use case is integration testing, verifying that your application calls the right operations with the right data, not production fidelity. For that, MiniStack works well and is free. For anything requiring exact DynamoDB behavior (capacity throttling, consistency window, stream processing), you're right that it's not a substitute. Contributions to improve error fidelity are very welcome (we have pending ProvisionedThroughputExceededException, TransactionConflictException, ItemCollectionSizeLimitExceededException)


I ran into the same thing with Kinesis. The Kinesis API has strict limits on batch size, message size, and rate limiting. Any client writing to Kinesis must deal with all of these constraints and handle errors properly.

I briefly looked at localstack to see how they implemented the Kenesis api and other than a `KINESIS_ERROR_PROBABILITY` option to simulate rate limiting, they did not implement any of the constraints.


Thanks for pointing this, I am adding a few extra validations in v 18 (to be released in a few hours) feel free to raise an issue, this is an open source project but I do review each PR and I keep the code as clean as I can... And yes we do use AI but we know what we are doing :)


I still think it's useful - you can do your base case testing against ministack and only start incurring AWS charges to finalize your load testing.


Neither does localstack to be fair.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: