61–70 of 88 posts
Earlier quoted context omitted.
[flagged]
Not really, the main thing they could change is the order in which errors are checked when there are multiple errors, but even a lot of that is not likely to change, eg html based stuff comes first. There are actual reasons for a lot of the subtleties, plus they have to have a stable contract for all the success cases as people rely on it. And its not hard to update, I have 800 or so tests against AWS that run in a f…
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.
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.
Earlier quoted context omitted.
Thus far I've tried that (rejected), Floci (not great), and now looking at this. This one is 7 days old. I'm eager to have a localstack replacement, but these are a long way off from being mature enough. I suppose this is just the new state of software? Shiny website, big claims, AI coded, insufficiently tested.
Out of curiosity, why did you reject Floci? It lacked some feature I needed, so I just went ahead and added them. My needs were not that complex and it has patterns to test that implementations match AWS. I agree it’s lacking things, but the bones aren’t that bad.
In particular my issues were: - missing range fetches (probably in place now) - Missing version support in various places - bugs wrt to the handling of versioned objects across api calls
My needs are not super mainstream, but I was better off using RustFS in this case. A single lightweight fake would be preferable though.
Earlier quoted context omitted.
"LocalStack was just a mess of a codebase" - very true. I do think there's potential to semi-automatically create a compatible suite of services, but it'll require some very talented use of LLMs and some novel testing approaches. Not something I want to sign up for. I evaluated Floci, but that has the typical issues you'd expected with freshly minted vibe code.
idk maybe AWS should create one? I mean, if we can use "virtual-AWS", it would dramatically lower entry-barrier for devs/companies who are scared of "tales of huge aws bills" and such
But we can still do that ourselves, dynamically interrogating the real thing and comparing it to the fake.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I am currently implementing S3, with correct error handling for edge cases. Its been about a month and I have almost the whole API surface done, with some gaps (you actually need a broader surface eg some IAM, KMS encrytion needs a persistence layer so only done sse-c so far). Close to the point where you could drop it in as a local emulation tool, its a sub 9MB binary (Rust). Literally as I write this the AI code re…
[flagged]
What’s the gcp equivalent
The real issue with LocalStack was always drift. Tests pass locally, then something breaks in staging because the S3 response format is slightly different or DynamoDB throttling doesn't match. After getting burned enough times we just switched to short-lived real AWS environments for integration tests. More expensive, but way fewer surprises in prod.