[flagged]
[flagged]
MiniStack (replacement for LocalStack)
31–40 of 88 posts
Re: MiniStack (replacement for LocalStack)
#32Any project with Claude’s signature misaligned ASCII diagram just screams DON’T USE to me. If you can’t even bother to read your damn generated README, how do I know you have QC’ed anything else? At the very least supported features claimed in README / on website could be totally fake, which is extremely common among all the vibed Show HNs. https://github.com/Nahuel990/ministack/blob/a1b1d20a27d2238d...
But brother, he is shipping at inference speed!
Re: MiniStack (replacement for LocalStack)
#33Earlier quoted context omitted.
Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence. If I’m getting into esoteric features or some “big” features that don’t make sense locally, then I just spin up a real dev account of aws, so I know I’m getting the real experience.
> getting into esoteric features The problem is that everybody needs different "core" features > > compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) For instance, I don't care about any of those features at all. But I would care a lot about EC2, RDS, and ElastiCache Redis
I'd put ALL the ones listed above: SQS, S3, KMS, DynamoDB, EC2, RDS, Redis in the required "core" services column, and also throw in IAM, SNS, and SecretsManager as well. Those are all table stakes imho.
I'm using all of the above in LocalStack today. Frankly, I don't believe this is as "impossible" a task as several in this thread are insinuating. It's the type of rote work you can delegate to AI to build these days, as observed in this OP.
Building a test suite to validate the state-transient mocks in question against the real deal is not difficult. Only annoyingly expensive (in time and money) if run often, which is exactly the problem they're solving.
Re: MiniStack (replacement for LocalStack)
#34Any project with Claude’s signature misaligned ASCII diagram just screams DON’T USE to me. If you can’t even bother to read your damn generated README, how do I know you have QC’ed anything else? At the very least supported features claimed in README / on website could be totally fake, which is extremely common among all the vibed Show HNs. https://github.com/Nahuel990/ministack/blob/a1b1d20a27d2238d...
Yeah. Could at least run a formatter on it afterwards... You can even configure a hook for Claude to do that.
Re: MiniStack (replacement for LocalStack)
#35[flagged]
Re: MiniStack (replacement for LocalStack)
#36The 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.
Re: MiniStack (replacement for LocalStack)
#37Any project with Claude’s signature misaligned ASCII diagram just screams DON’T USE to me. If you can’t even bother to read your damn generated README, how do I know you have QC’ed anything else? At the very least supported features claimed in README / on website could be totally fake, which is extremely common among all the vibed Show HNs. https://github.com/Nahuel990/ministack/blob/a1b1d20a27d2238d...
We live in the golden age of slop. It seems a surprisingly small number of people have the visceral AI disgust response.
Maybe that visceral response being against the rules (assume good faith) and actively being punished explains the small number of people doing it?
Re: MiniStack (replacement for LocalStack)
#38Earlier quoted context omitted.
Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence. If I’m getting into esoteric features or some “big” features that don’t make sense locally, then I just spin up a real dev account of aws, so I know I’m getting the real experience.
> getting into esoteric features The problem is that everybody needs different "core" features > > compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) For instance, I don't care about any of those features at all. But I would care a lot about EC2, RDS, and ElastiCache Redis
Interesting — those are the ones that depending on the case, approximating them with local redis/postgres/vms without the AWS specific APIs on top is often good enough — because my app is just talking to them over native protocols anyway.
Or I am doing something so specific, that a local emulation of the aws api isn’t ever going to be good enough, so there’s not a lot of point in trying. For example, writing code that handles automatically spinning up RDS instances from an RDS snapshot — a local emulation of that process is going to be so far off from what would actually happen no matter what they do.
Re: MiniStack (replacement for LocalStack)
#39I really don't see how any clone is going to manage to do what localstack couldn't - maintain compatibility with tons of AWS services while not getting paid for it. If this were viable, why would it not have worked before? The only things I can think of are that perhaps LocalStack was just a mess of a codebase that couldn't maintain velocity or attract contributors, or it just failed to steward new contributors or so…
That's true if you assume making these things is manual work. But of course with well documented API service and AI coding tools, making a functional local equivalent of any given service is not all that hard.
Re: MiniStack (replacement for LocalStack)
#40The 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.
i would imagine localstack is a sniff-test - aka, if it doesn't pass localstack, you don't run the more expensive real AWS integration test. In other words, like food, you don't eat the cost unless it passes the sniff test.