Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Convex vs. Firebase

docs.convex.dev

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Convex vs. Firebase

#21

Post by fakedang »

danielvaughn wrote: post #11
TekMol wrote: post #6

According to the article, this is how you load messages and their users from a DB via Firebase: const querySnapshot = await getDocs(collection(db, "messages")); const userSnapshots = await Promise.all( querySnapshot.docs().map(async messageSnapshot => { return await getDoc(docSnapshot.data().creator); }) ); Phew! Thanks, but no. Never. I will keep doing it server side: $messages = DB::select( 'SELECT * FROM messages…

Technically that's how you load data from Firestore specifically, but yes, that's how it's done. I started working with a team who uses Firestore, and let me tell you, I've never hated a database so much. No disrespect to anyone from the Google team, but I cannot fathom why they made the decisions they made. 1) You are severely limited in how you can query. The list of limitations is too long to recount here, but que…

> It gears itself towards frontend developers who don't know how to write a backend, and encourages bad practices for them. One example: Firebase lets you manually edit production data very easily from within their dashboard. Like it's treated almost like it's a CSV.

This is truly spot on. I'm one of those devs who couldn't write a good backend when I first began coding out apps (as a hobby). Started out with firebase because that was the tool used by most YouTube videos and Medium blog posts introducing people to app development. In the end, I eventually had to learn other technologies such as using Elasticsearch, DynamoDB (which I would also stay the hell away from) and PostGRES.

Thankfully Supabase decided to stay away from the NoSQL format, so learning how to get started with PostGRES was made smoother.

Looking back I don't even know why I jumped into using Firebase, since I do have a pretty good footing in SQL querying. I don't know why Google isn't bothering with an Elasticsearch-like NoSQL solution for Firebase. And quite frankly, I would only use Firebase for Auth and RTDB for basic database stuff. If I had known this earlier, I might have saved months of learning Firebase Cloud Firestore crap online.

Re: Convex vs. Firebase

#23

Post by aboodman »

aboodman wrote: post #22

I don't get it. Firebase has functions as a first class citizen: https://firebase.google.com/products/functions

To be clear, I think it's great for Firebase to have competition (same feeling as e.g., supabase). But the "you can only load documents" argument doesn't seem technically correct to me.

Except for maybe in the sense that convex is built on functions from day one so the docs and platform will lead you there by default rather than loading the documents which is non-optimal.

But that's a different argument than:

> With Cloud Firestore, the client interacts with its data by loading documents straight from the database.

Re: Convex vs. Firebase

#24

Post by alexcole »

aboodman wrote: post #22

I don't get it. Firebase has functions as a first class citizen: https://firebase.google.com/products/functions

Absolutely. But if you decide to use Cloud Functions with Firebase you have to give up the reactivity and automatic optimistic updates that Firebase normally provides.

Part of the difficulty of writing about Firebase is that it's actually a whole collection of tools with a host of complex tradeoffs. But that's also a lot of the difficulty in using it as well! Understanding when to use Cloud Firestore vs Realtime Database and when to load data directly vs via Cloud Functions are all complex questions with unclear answers.

Re: Convex vs. Firebase

#25

Post by tlarkworthy »

james_cowling wrote: post #13
tlarkworthy wrote: post #7

I was an early developer at Firebase. I think we made Firebase so easy to use and never spoke on about the technicals that the whole software ecosystem now underestimates the complexity involved. I see various Firebase competitors asserting various "mistakes it makes" without really understanding what it delivers, which is understandable because we never marketed it like that because we spoke only about how it can he…

Thanks for the feedback. We think React is the right community to target right now but the end state for Convex is certainly not limited to React. The specific concern with regards to multiple round trips is scenarios where the client needs to send multiple serial requests to render a web view, e.g., having to fetch a list of posts first before knowing which post ids to fetch comments for. These request waterfalls ca…

I spoke at HYTRADBOI too! https://www.hytradboi.com/2022/creating-a-wire-compatible-fi...

> Consistency-wise Convex supports full serializability.

As discussed elsewhere both Firebase DBs too and also provide clients with a causally consistent snapshots too, so you are not actually adding anything over the Firebase offering. Firebase has optimistic updates too and can use clientside persistent storage (I think convex has just an in-memory cache at the moment).

> e.g., having to fetch a list of posts first before knowing which post ids to fetch comments for.

Yes this does perform badly. Though this type of join is also an IO hog on a relational DB too, just it's not so visible.

Re: Convex vs. Firebase

#26

Post by tlarkworthy »

aboodman wrote: post #22

I don't get it. Firebase has functions as a first class citizen: https://firebase.google.com/products/functions

Actually I think Convex team are right, synchronous functions or database views would be huge improvement to Firebase.

Firebase Functions are asynchronous, and can be reordered relative to DB operations. They would be much more powerful if synchronous and on the wrtie path (so you could put auth logic in them instead of being forced to use the bespoke security language).

Firebase functions are at-least-once though, so they are pretty good but could be better.

Re: Convex vs. Firebase

#27

Post by RayVR »

I built a fairly involved mobile application that used Firestore and cloud functions. The criticisms of the two made in the article are very fair. I also think there are even more significant ramifications of the issues touched on which result in horrible problems for developers.

I have a lengthy list of complaints about both firestore and the firabase flavor of cloud functions, however, I will say that the ease of getting started with the firebase suite is unmatched, in my experience. Compared to any product on AWS or raw GCP, it feels like an actual product with people thinking about their users.

There is also a large community around the firebase products, the main example being Invertase.io which provides amazing open source native clients for firebase.

Regarding Convex specifically, the approach of writing queries server side seems great. The docs aren't clear (to me) about whether the queries only send incremental state changes. I would assume and hope that is the case.

In this bit[1] it seems like the function needs to execute the entire query again, which could become a significant performance issue.

[1] https://docs.convex.dev/understanding/convex-fundamentals/fu...

Re: Convex vs. Firebase

#28

Post by tlarkworthy »

ceeplusplus wrote: post #18
danielvaughn wrote: post #11

Earlier quoted context omitted.

Technically that's how you load data from Firestore specifically, but yes, that's how it's done. I started working with a team who uses Firestore, and let me tell you, I've never hated a database so much. No disrespect to anyone from the Google team, but I cannot fathom why they made the decisions they made. 1) You are severely limited in how you can query. The list of limitations is too long to recount here, but que…

It suffers from trying to go upmarket with something that was never meant for ultra-serious, large, production apps. Look at the original Wired article [1]: every story of the founders' pitching to customers is about being able to quickly zero-to-one a concept. It seems great for internal apps, quick prototypes, and simple things and that's about it.

Firestore has better SLO than Confluent's own managed Kafka offering (5 nines [1] vs 4 nines [2]).

If you use it as a system component and not a do everything backend it is the most production ready clientside technologies on the planet.

[1] https://docs.confluent.io/cloud/current/clusters/cluster-typ...

[2] https://cloud.google.com/firestore/sla

Re: Convex vs. Firebase

#29

Post by randomdata »

mquander wrote: post #16
danielvaughn wrote: post #11

Earlier quoted context omitted.

Technically that's how you load data from Firestore specifically, but yes, that's how it's done. I started working with a team who uses Firestore, and let me tell you, I've never hated a database so much. No disrespect to anyone from the Google team, but I cannot fathom why they made the decisions they made. 1) You are severely limited in how you can query. The list of limitations is too long to recount here, but que…

I also just joined a team using Firestore and I feel exactly this same way. It absolutely blew me away how bad Firestore is for any kind of conventional CRUD app use cases. I have never worked with a database less fit for purpose, and I worked with MongoDB in 2012.

Yup. One of our products was built on Firestore and I expect 90% of my time on that project is spent trying to turn Firestore into a more featureful product to meet the application's requirements. You can push it pretty far if you have the developer resources, but it often seems ludicrous that someone is willing to spend that much to build what other database solutions provide out of the box for free.

Re: Convex vs. Firebase

#30

Post by _vvhw »

The founders of Convex are some of the most talented developers I know.

The CTO worked with Turing-award winner Barbara Liskov on Viewstamped Replication Revisited [1], the revision of the pioneering consensus protocol, and later the founding team pulled off the migration of Dropbox from S3 to their own custom storage stack called Magic Pocket [2].

The deterministic simulation testing techniques [3] they used to develop Dropbox's revised sync algorithm are still state of the art today (few systems are designed to be tested like this), and the online verification techniques [4] they used to verify their production systems are vital to building large-scale systems safely.

I can't think of a stronger technical team to do something like Convex, and couldn't imagine a better devops team to be running the backend.

[1] https://pmg.csail.mit.edu/papers/vr-revisited.pdf

[2] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama...

[3] https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

[4] https://www.oreilly.com/library/view/velocity-conference-new...

Post reply on HN