211–220 of 308 posts
I saw the reference to “apps like Figma” and as one of the people that worked on Framer’s (also a canvas based app) database which is also local+multiplayer I find it hard to imagine how to effectively synchronize canvas data with a relational database like Postgres effectively. Users will frequently work on thousands of nodes in parallel and perform dragging updates that occur at 60 FPS and should at least be propag…
tl;dr -- I'm a big fan :)
Is this similar to CouchDB/PouchDB? Can the backend be replaced?
Ah, sorry. I thought this was a firebase alternative in the sense that it's an open source library that works with Postgres, but it's a cloud storage service with a nifty frontend.
The github repo includes the server
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 u…
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...
I'm wary of stuff like this, probably really useful to rapidly iterate.... but what a maintence nightmare after 10 years and your schema has evolved 100 times, but you have existing customers in various state of completeness. I avoided firebase when it came out for this reason. I had a few bad experiences with maintaining applications built on top of Mongo that made it to production. It was a nightmare.
In other words it primarily targets brand new projects or projects that can completely migrate away from their current database?
This is super exciting! I was literally just wondering if something like this existed a few days ago (seriously)! Some super minor feedback appended. All the best with InstantDB! There is a missing word in the message that appears after clicking on the "Create an app" button: > With that one-click you’ve claimed an id that you can use for storing your data. Now we'll show you [how] to wire up your db to an app and st…
1) Added in the 'how'
2) Changed the sentence on mobile to say: 'Check out the walkthrough below, and the full code example right after.'
Earlier quoted context omitted.
This is a great question. We are working on a more concise transaction API, and are still in the design phase. Writing a `user.save()` could be a good idea, but it opens up a question about how to do transactions. For example, saving _both_ user and post together). I could see a variant where we return proxied objects from `useQuery`. What would your ideal API look like?
We have an internal lib for data management that’s philosophically similar to linear too. I opted for having required transactions for developer safety . Imagine that you support the model discussed above where it’s possible to update the local store optimistically without syncing back to the db. Now you’re one missing .save() away from having everything look like it’s working in the frontend when really nothing is p…
Mark (our team member) has advocated for a callback-based API that looks a lot like what you landed on. It has the advantage of removing an import too!
Question: how do you solve the 'draft' state issue that remolacha mentioned?
Earlier quoted context omitted.
I always assumed that an architectural decision had prevented relational queries in Firebase. It was jarring to find out that indexes are required for every combination of filters your app applies, but then you quickly realize that Firebase solves a particular problem and you're attempted to shoehorn into a problem-space better solved by something like Supabase. It's not too dissimilar to DynamoDB vs RDB.
> I always assumed that an architectural decision had prevented relational queries in Firebase. Seems the biggest problem is that Firebase doesn't have relations. How can you query that which does not exist? I'm guessing what they really want is SQL? Once upon a time when I was stuck on a Firebase project I built a SQL (subset) engine for Firebase to gain that myself, so I expect that is it.
But I can’t.
Why not the standard node.js with shared module? Assuming performance is not the primary goal.
Why not generated rust structures from model file and a rust server? Assuming performance is the primary goal.
Why not a jvm with a lightweight runtime? (Assuming instancing is used for scale here, a lot of wasted ram usage here)