Comment by mattfrommars
2 years ago
I read the whole thing but I fail to understand how does this help or fit into picture of CRUD app. Most app I interact and work for a living are essentially a CRUD, SQL Server and a DOA layer by Spring.
How do I need to start thinking conceptually for this, InstantDB or Firebase concept to kick in?
Say for a collaborative text editor, I'd use off the shelf CRDT Javascript implementation.
Imagine a you want to create a 'todo' list.
If you used classic Rails, you'd be very productive. You could write most of your code on the server, and sprinkle some erb templates.
However, if you want to improve the UX, you generally end up writing more Javascript. Once you do that, things get hairier:
You create REST endpoints, funnel data into stores, normalize them, and denormalize them. Then you write optimistic updates. If you want offline mode, you worry about IndexedDB, and if you want it to multiplayer, you end up with stateful servers.
If you had a database on the client, you wouldn't need to think about stores, selectors, endpoints, or local caches: just write queries. If these queries were multiplayer by default, you wouldn't have to worry about stateful servers. And if your database supported rollback, you'd get optimistic updates for free.
This is the inspiration for Instant: it gives you a 'database' you can use in the browser.
If you're curious, I wrote a more detailed essay about this here:
https://www.instantdb.com/essays/db_browser#client
> If you want offline mode, you worry about IndexedDB
I don't understand the offline mode. If I was to make a single player offline game that runs on the browser, sure, offline mode makes sense and I want to store on client machine.
But in the space of web apps, everything data needs to be synced with server db.
Why would I want to store half of my to do list on client and other half on the server? The end goal is the customer data is stored in the cloud...
So the user could keep working on a plane, when cable, or electricity is out, etc. Wants to experiment without inflicting changes on others, like dvcs. The user may not have “their data on your cloud” as an end goal.
There’s a paper by Kleppman et al about local-first apps that is worth a read.
2 replies →
I'm a bit naive here, so asking a stupid question. I have an `offline only` app where I read things from the file system (markdown) and currently store them in a redux state for accessing filepaths and ids.
I've been planning to move to indexedDb using dexie for kinda the same use case of easier transaction, not maintaining a huge redux state (16k lines or so), and improved performance.
Now if my app is not supposed to be backed by a online database (single player only, complete offline), would instant make sense for this?
or would indexedDB be the safer choice?
I would not recommend using IndexedDB as your primary storage. This is because browsers can sometimes delete the underlying store (there are various reasons for this, but one is that the user is running out of space on their machines) [1]
If you have access to the file system, I would consider using SQLLite to store everything. If you end up then wanting auth / collaboration, you could try Instant.
[1] This is a good comment that goes deeper https://news.ycombinator.com/item?id=28158407
1 reply →