153 points•theanonymousone•4 days ago•78 comments•

78 comments

otterley3 days ago
There’s also MiniStack, which forked from LocalStack after they started breaking developer workflows: https://ministack.org/

Both fakecloud and its website look sloppily vibe-coded, and its “authors” are anonymous. It’s going to take a while for it to earn trust. I’d treat it with suspicion. (Curl-to-shell pipe to install? Ugh.)

tingletech3 days ago
> and its “authors” are anonymous.

The blog posts are all attributed to "Lucas Vieira" and the dev group https://faisca.dev that is attributed as the author has 2 other projects. Lucas comes up in LinkedIn and looks like an actual person working in San Francisco.

Re: curl; this seems to work:

  cargo install fakecloud
losteric3 days ago
faisca.dev is also vibed - perhaps it's a real human using AI to build an online fascade
dmacvicarabout 5 hours ago
MiniStack is not (as I remember), a fork of LocalStack.

Disclaimer: I work for LocalStack

straygarr3 days ago
Agreed with everything up to:

"curl-to-shell pipe to install" - what's the problem here? that's pretty common on linux systems and something the AWS CLI uses.

Or is the problem the fact that this dev is untrusted and is executing a possibly malicious script on your machine?

jasongi3 days ago
For a mock server? Surely a versioned, standalone executable, library/package or docker image makes more sense. Integration tests generally need to be portable and running on CI, you don't wanna be shell-piping whatever exists in the moment.
ssl-33 days ago
The problem, for me, is that self-running installers can create a mess that's hard to keep track of.

I've run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.

There's no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&&sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.

I've found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.

MisterMunchkin3 days ago
Running arbitrary code directly in your terminal is very dangerous
sdcfgy3 days ago
I'm worried that this behaviour has to be defended.
x3n0ph3n33 days ago
curl-to-shell is a terrible installation mechanism because it's not easily reversible and I can't tell if any of the assets are signed, or integrity checked, or not.
iLoveOncall3 days ago
> Both fakecloud and its website look sloppily vibe-coded

As if the MiniStack website wasn't also obviously vibe-coded lol.

nnucera3 days ago
Yes, the prompt was: "Make a Ministack website. Make no mistakes" Does that make it less useful?

You can check who’s using Ministack on public GitHub repos, NVIDIA, Block, NASA, the U.S. gov, the UK gov, and many others. There are plenty of examples demonstrating that we’re doing something good

If you still want to use COBOL because it makes you feel better or smarter, good for you. That doesn’t mean Ministack lacks quality

otterley3 days ago
It probably is, and that’s not great, either.
joshribakoff3 days ago
Instead of a simulator that runs in its own process, I would recommend mocking out inline in the tests. Only then are your tests entirely “self contained”.

Otherwise your test implicitly make assumptions like “User A is always off-line” (or bucket A is always empty), add a reader of the test would have to go find where that assumption is hardcoded in the simulator and verify it separately from the test itself.

To someone reading that test it is not intuitive that user A is always off-line or bucket A is empty.

If you mock out in line, you can have tests that mock user a / bucket a — to simulate any state for any user or bucket. Perhaps multiple states in one test.

Also think about scenarios like the bucket is initially populated, but then on a subsequent request, it’s empty.

With the simulator approach, you’d have an endless number of permutations of scenarios to add — each of these scenarios would be highly coupled to the test it belongs to, so why not just put it in line in the test itself?

Any reader of the test that uses inline mocking would clearly see which scenario is being tested instead of having to dive into a separate simulator to see what special treatment is hardcoded for User a / bucket a (or maintaining potentially hundreds or thousands of simulated buckets with ad hoc names like “empty-on-second-request” or “bucket–that-responds-slow-and-times-out-but-succeeds-on-retry”.

regularfry3 days ago
That's fine if the interaction with the service is within the scope of your code. If you want to, say, mock out terraforming a bunch of IAM permissions to least-privilege a lambda such that you can check it actually works, you don't have a seam where any app-level tests can go in.

That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.

hk13373 days ago
And if you want to see how they all interact together in AWS, that's why you have a development sandbox AWS account.
bushbaba3 days ago
Better yet, use dependency injection and use fakes. Makes it very easy to test out logic
shermantanktop3 days ago
There are so many of these, but none of them simulate the surprise-billing experience.
igetspam3 days ago
File a feature request! ;)
arpinum3 days ago
"46 at true 100% conformance". This is factually incorrect. Inspected their DynamoDB service and it comes nowhere close to implementing the full api.
arpinum3 days ago
Here are some bugs: - `ADD m.a.c :inc` update expression wrote a literal top-level m.a.c attribute but didn't change the nested number. - TransactGetItems returned fields not requested. - update expression can update the same key multiple times.

In total my conformance suite found 583 failures out of 1279 tests.

lucas_vieira3 days ago
Thank you. I'm going through the DynamoDB issues now, starting with the three you listed. The Parity Suite is great. I'm wiring it into fakecloud's CI.
equinumerous3 days ago
Wow! This is not production-ready at all. DynamoDB would be my main use case. I'll stick with DynamoDB local.
bilekas3 days ago
There are always nice, but there are a lot of scaffolding work involved with larger systems. It would be nice to be able to provide for example the terraform of the infrastructure and let these tool create their own. Might be a nice feature to add because I haven't seen it done yet.
igetspam3 days ago
I use tf with floci and floci-gcp, weekly…
_joel3 days ago
Oh nice, not aware of this. We're opentofu on GCP, so could be a good addition to ci

Read the full thread on Hacker News →

Related stories