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.
Show HN: InstantDB – A Modern Firebase
201–210 of 308 posts
Re: Show HN: InstantDB – A Modern Firebase
#202[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story). Good luck, Joe, Stopa and team!
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.
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.
Re: Show HN: InstantDB – A Modern Firebase
#203Re: Show HN: InstantDB – A Modern Firebase
#204Re: Show HN: InstantDB – A Modern Firebase
#205Earlier quoted context omitted.
A thenable API from save() could remove the need of a explicit tx management which is a worse devEx
I’m not quite seeing what you mean. What you mind redoing the example above for my benefit? We have controllers that all the users actions are funnelled through. The top level functions in there are wrapped in transactions so in practice it’s not something you manually wrangle.
Re: Show HN: InstantDB – A Modern Firebase
#206Earlier quoted context omitted.
A thenable API from save() could remove the need of a explicit tx management which is a worse devEx
I’m not quite seeing what you mean. What you mind redoing the example above for my benefit? We have controllers that all the users actions are funnelled through. The top level functions in there are wrapped in transactions so in practice it’s not something you manually wrangle.
author.save()
.then(() => {
const article = new Article(db);
article.name = "New name";
article.author = author;
return article.save(); // could be used to chain the next save
})
.then(() => {
console.log("Both author and article saved successfully.");
})
.catch((error) => {
console.error("rollback, no changes");
});
but I confess I might have said that without having the same understanding of the problem as you so might be nonsense. it just happen that I decided to implement transactions this way in a side project of mine.Re: Show HN: InstantDB – A Modern Firebase
#207Seems comparable to https://pocketbase.io/
Re: Show HN: InstantDB – A Modern Firebase
#208Earlier quoted context omitted.
Co-founder of PowerSync here. Would love to hear what you would like to see improved in PowerSync :) Thanks!
ElectricSQL before their announced rewrite worked fully offline and could sync when the clients became online again. Now, that functionality with their rewrite is somewhat removed, as they expect you to handle clientside writes by yourself, which is what I believe PowerSync does as well, am I correct in that understanding? If I wanted a fully offline clientside database that could then sync to all the other clients w…
Yes, that is correct.
> If I wanted a fully offline clientside database that could then sync to all the other clients when online, what would I do? I am looking for this in the context of a Flutter app, for reference.
This is what PowerSync provides by default. If you haven't done so yet, I would suggest starting with our Flutter client SDK docs and example apps — and feel free to ask on our Discord if you have any questions or run into any issues :)
Re: Show HN: InstantDB – A Modern Firebase
#209However, it didn't scale well in terms of performance to large numbers of users.
Would anyone have thoughts on comparisons to Meteor?
Re: Show HN: InstantDB – A Modern Firebase
#210Some 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 start adding data. Check out the walkthrough below on your left with the full code and preview on the right.
Also on smaller screen sizes there is no left and right. :)