Live data from Hacker News

Show HN: InstantDB – A Modern Firebase

github.com

201–210 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#201
post #193

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.

This is why I’ve always stayed well behind the bleeding edge but still within earshot if anything comes along that sounds like it’s of interest to me. I usually code to work and not for pleasure, although I do a little web programming for friends, but I still use jQuery and Typescript for that, I think the only “new”thing I use is tailwind, which is a bit of a game changer for what I like to do, I never liked CSS but it worked well enough for my needs.

Re: Show HN: InstantDB – A Modern Firebase

#202
post #7

[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.

> 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.

Re: Show HN: InstantDB – A Modern Firebase

#205
post #194

Earlier 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.

[deleted]

Re: Show HN: InstantDB – A Modern Firebase

#206
post #194

Earlier 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.

I was thinking about something like:

  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

#208
post #65

Earlier 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…

> 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?

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

#209
A really exciting product from many years ago was Meteor, which included a realtime database layer on top of Mongo that facilitated many very novel realtime apps.

However, 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

#210
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 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. :)

Post reply on HN