So, give your LLM a URL and tell it to follow the instructions there? Err, no thanks.
Most LLMs in practice already read URLs. If you ask them a question they don't know, they will search and read pages.
Show HN: GETadb.com – every GET request creates a DB
11–20 of 49 posts
Re: Show HN: GETadb.com – every GET request creates a DB
#12I thought this would be something about getting (downloading?) the Android Debug Bridge tool (adb) until I read further. Might want to capitalize DB as well (GETaDB), at least from my pov
[deleted]
Re: Show HN: GETadb.com – every GET request creates a DB
#13Re: Show HN: GETadb.com – every GET request creates a DB
#14I thought this would be something about getting (downloading?) the Android Debug Bridge tool (adb) until I read further. Might want to capitalize DB as well (GETaDB), at least from my pov
Ah, good point. We can't change the title now though.
Re: Show HN: GETadb.com – every GET request creates a DB
#15The 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...
Re: Show HN: GETadb.com – every GET request creates a DB
#16I found https://www.instantdb.com/about very interesting; you built a new database! The triples stuff is cool.
For GETadb, it's a conflicting sell. The people that need "a db solved by AI" and fully abstracted are using app builders no? lovable, v0, manus. The people the are closer to the code and need an instant db would look to sqlite, render, supabase, neon. I'm all for another option, but then there's the realization that instandb is a new kind of db and I need to research into the value-prop vs the initial persona: "just solve my db problem with AI".
disclaimer: I'm a professional developer, doing an honest review. I may play around with it separately, later. So this marketing site did its job!
Re: Show HN: GETadb.com – every GET request creates a DB
#17The 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.
Re: Show HN: GETadb.com – every GET request creates a DB
#18The biggest problem I see with vibecoded apps attached to a db is that the db is configured with exactly 0 access control (even if whatever backend does support it), and anyone can turn up and SELECT * FROM users, or even DROP TABLE users. How do you mitigate this?
Re: Show HN: GETadb.com – every GET request creates a DB
#19Earlier quoted context omitted.
Thank you! Yeah, it is surprising how magic words can impact the performance of LLMs
do you actually know or are you just guessing
Funny enough we added this in awhile back when it seemed more conclusive that this does matter.
But I was curious and just did an adhoc eval.
Here's a version with the aesthetic line included
Here's a version without the line
Everything else is the same. Will let y'all be the judge which is better.
Both where made in one-shot with this prompt:
Create a habit tracking app where users can create habits, mark daily completions, and visualize streaks. Include features for setting habit frequency (daily/weekly), viewing completion calendars, and tracking overall progress percentages.
Re: Show HN: GETadb.com – every GET request creates a DB
#20The biggest problem I see with vibecoded apps attached to a db is that the db is configured with exactly 0 access control (even if whatever backend does support it), and anyone can turn up and SELECT * FROM users, or even DROP TABLE users. How do you mitigate this?
Good question. Two ways:
1. For the users table specifically, we have a default rule that says `"view": "auth.id == data.id"`. This way even if the the user (or AI) did not set access controls, user data is protected by default.
2. In the instructions file given to the agent (https://www.getadb.com/provision/new), we specifically mention permissions and how to push them. We found this prods the agent to push perms.