221–230 of 308 posts
Earlier quoted context omitted.
Tetrafecta would be cooler
Cursory googling says tetra is Greek and perfect is Latin, so its a bastard word like erogenous or television.
From where I am, it is simply telly, because why not bastardise it some more while we are at it.
Interesting that this is Clojure :-) Clojure + TS seems to be a good way to go, without being hung up on CLJS.
TS as in TypeScript? They're on two very opposite ends of a spectrum, what would you use it for if you're already using Clojure? And what's the "hang up" with CLJS?
Earlier quoted context omitted.
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…
You make a great point about missing .save(). 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?
Forms just inherently can have partially-finished/invalid states, and it feels wrong to try and kraal model objects into carrying intermediary/invalid data for them (and in some cases won’t work at all, eg if a single form field is parsed into structured data in the model)
Earlier quoted context omitted.
> 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.
Building a logistics app, I wish I could query in Firebase for items that don’t have a “shipped” field. But I can’t.
I have been eyeing Electric SQL lately for developing a local-first app. How does InstantDB compare with Electric SQL? Side note: Electric SQL is currently going through a rewrite, so things are a bit up in the air.
If that understanding is correct, then InstantDB may be a good fit if you are starting your database from scratch or can completely get rid of your existing one.
I have more than 170GBs of data in a SQL database. I can sync parts of it to ElectricSQL using shaped queries.
Earlier quoted context omitted.
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…
> 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 th…
There’s a paper by Kleppman et al about local-first apps that is worth a read.
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.
For what it's worth, we're built on top of Aurora and support relations so evolution should be much easier!
[1] https://mdp.github.io/2017/10/29/prototyping-in-the-age-of-n...
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.
Did they say schemas aren’t supported, or is that implied by the firebase label?
Why clojure (and by proxy Java?). I don't have a problem with either, but it puzzles me quite a bit. 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…
Also the clojure community is amazing. The clojurians slack is one of the most helpful communities for solving hard problems. Stopa will be giving a talk at at the conj later this year [1]
Is it correct to assume that if your existing application has lots of data stored in standard PostgreSQL tables, you can't have InstantDB sync with it? In other words it primarily targets brand new projects or projects that can completely migrate away from their current database?
The way the Postgres adapter would work: You give us your database url [1], and Instant handles the real-time sync. [2]
For roll-out, we'll test it ourselves first and then take on beta users.
[1] Encrypted at rest: https://github.com/instantdb/instant/blob/main/server/src/in...
[2] Here's a fun 'pg introspection' function: https://github.com/instantdb/instant/blob/main/server/src/in... . You can take sneak peak through codebase by searching 'byop'.