Live data from Hacker News

Show HN: GETadb.com – every GET request creates a DB

getadb.com

31–40 of 49 posts

Re: Show HN: GETadb.com – every GET request creates a DB

#31

The GET request method is supposed to be safe. "Request methods are considered 'safe' if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource." -RFC 9110 section 9.2.1 https://www.rfc-editor.org/rfc/rfc9110.html#name-safe-method...

Here's my argument: In practice many GET requests don't adhere to this spec. For example, when you load a page, your "view" generally changes lots of things on the backend. Those changes come back to you in ways too: for example, consider view counts on Youtube videos or X posts.

These are just conventions, one can pretty much do whatever they want in their applications. At the same time convention has its own advantages (most of the times, think about code maintenance). Its still along the excepted line as long as the mutations are side effects of the GET request. Somewhere down the line the intent is to provide a separation to easily understand the systems.

Re: Show HN: GETadb.com – every GET request creates a DB

#32
post #26

Earlier quoted context omitted.

You are right about the activation energy to throw up anything new really comes down to a hosted db that won't rot. My initial experience with supabase was incredible in that sense: any client-side framework I wanted, deployed statically while still integrating with full Postgres, for free! Problem is supabase rots. And turning that project into anything meaningful is basically undoing everything you got for free up…

As someone looking to use supabase for a project, I'd love to learn more about what you mean by supabase rots - did you run into scaling problems?

For me, not scaling, the opposite of scaling. For the scaling side there's two much more involved posts about the topic: https://news.ycombinator.com/item?id=36004925, https://news.ycombinator.com/item?id=48038827

For toy apps and initial prototypes the problem is they aren't going to get used so the rot is that they will be in a good-enough state to come back to when you get the time. With supabase the drop-in auth completely broke at some point, probably just a deprecation I didn't keep up with.

The postgres instance spins down when you aren't using it, which is understandable and I will say it works, it's just Postgres and you get the database dump if you need to move or come back a year later.

The nuance here is that you get the raw connection string + the postgREST API which all makes sense but you're choosing full cloud/client mode which is completely different from if you just went with the raw connection string behind a server layer. I kinda had to work through all of that learning on my own. The full client mode trade-off is that you'll be doing everything with that pattern, handling migrations, security, auth, it's just kinda... it's a whole thing. The public postgREST and row level security is a different paradigm.

as a professional dev, I would have just chosen the raw connection string and managed the database from the server until I outgrew it and I'd have the dev workflow already, it's just a Postgres db. Or sqlite to start, same reasoning it's all the same dev workflow, the problem is the cloud-hosting transition, which is why fully-managed cloud db accessible from an edge/client runtime is so alluring, but you're trading two very different ergonomics.

I'm thought-dumping, gotta run, hope this helps.

Re: Show HN: GETadb.com – every GET request creates a DB

#37
I’ve tried this and I like it. I’d like a platform like Instant but with the addition of a web based text editor and Claude Code / Codex terminal (provide own subscription/api key) that lets you create and edit (create previews, then promote to production) the app from the same interface, alongside the managed db.

Re: Show HN: GETadb.com – every GET request creates a DB

#38
post #7

I appreciate this part of the agent instructions: `AESTHETICS ARE VERY IMPORTANT. All apps should LOOK AMAZING and have GREAT FUNCTIONALITY!`

Trump's tweet style might be onto something.

I thought the same thing!

Re: Show HN: GETadb.com – every GET request creates a DB

#39
post #33

reading https://www.getadb.com/guide > Generate a random UUID yourself and use a different UUID each time. LLMs are terrible at this. If you are relying on this to prevent collisions, it will fail badly.

The UUID doesn’t actually affect the response. Every GET request still generates unique credentials each time, no matter what the value is that passes to /provision/

We added it to help the app builders that do a lot of caching get unique responses. Turns out even if you set no-store cache headers, some app builders cache the pages. We tested this idea with those app builders and saw that they did generate uuids each time.

Post reply on HN