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 programmer, doing an honest review. I may play around with it separately, later. So this marketing site did its job!
"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
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.
The 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?
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.
I 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
I 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 programmer, doing an honest review. I may play around with it separately, later. So this marketing site did its job!
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.
The 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?
I appreciate this part of the agent instructions: `AESTHETICS ARE VERY IMPORTANT. All apps should LOOK AMAZING and have GREAT FUNCTIONALITY!`
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
https://with-aes.vercel.app/
Here's a version without the line
https://wo-aes.vercel.app/
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.
I 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.
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.
This is very cool!
But why do we need this? An agent can just have a local DB using SQLite for example.
Two reasons this could make sense:
1. With this, agents can actually deploy a full backend with their credentials [^1].
2. If your agent ever wants to add auth, or real-time presence, or file uploads, or streams, they'll be able to do that too
[^1] Alas we don't offer static site hosting, so to push the website you would need to use something like a vercel cli.
The agent thing is going a bit out of hand here.
Admittedly stateful GET requests are heretical, but it may be the future!