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

1–10 of 85 posts

Re: Convex vs. Firebase

#2

Post by rockwotj »

Firestore does provide global consistency, so the following quote is incorrect:

> In Cloud Firestore, the data on the client are loaded from the database at different points in time. Even if you listen for realtime updates, results from separate queries will not remain in sync. This creates consistency anomalies and bugs in your app.

Here is a link to the protocol documentation that the clients use to support it: https://github.com/googleapis/googleapis/blob/d0b394f188e8c3...

I'd link to the client implementation but it's quite involved.

There are ways to opt of of this and get stale cached data if you're offline, but you're explicitly opting in at that point

Re: Convex vs. Firebase

#4

Post by rockwotj »

So the reactivity here is based on smart polling?

> Later on, if any mutation inserts, updates, or deletes a record that overlaps with the read set, Convex knows it needs to recompute the listMessages query. If the result of listMessages changes, the new value is synced to the client and the component rerenders.

FWIW Firestore is able to send incremental updates and not just rerun the query when data changes. There is a complex system for broadcasting individual documents as the commit happens. I posted a bit about this a long time ago: https://news.ycombinator.com/item?id=26910411

Re: Convex vs. Firebase

#5

Post by james_cowling »

rockwotj wrote: post #4

So the reactivity here is based on smart polling? > Later on, if any mutation inserts, updates, or deletes a record that overlaps with the read set, Convex knows it needs to recompute the listMessages query. If the result of listMessages changes, the new value is synced to the client and the component rerenders. FWIW Firestore is able to send incremental updates and not just rerun the query when data changes. There i…

I'm not sure what your definition of smart polling is but there is no polling going on here - the query only reruns when the data dependencies change server-side due to a subsequent mutation.

Another key distinction is that "query" here doesn't refer to a database read, it could be a complex function containing multiple reads, relatively-arbitrary compute, etc.

Re: Convex vs. Firebase

#6

Post by TekMol »

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 JOIN users ON users.id=messages.user_id'
    );
It is amazing with how much cruft developers are willing to deal with these days. And how much CPU cycles get burned for nothing, as the Firebase example fires one query per message to get the user. This would be bad enough on the server. But with the Firebase example, it would also create a client-server http roundtrip for each message. Mind-boggling.

Re: Convex vs. Firebase

#7

Post by tlarkworthy »

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 help you build easier.

The idea that n queries instead of a join is slow is not as true as you would think. Firestore supports streaming and pipelines at its core, and can reuse cache across operations. At the end of the day, the data goes over a narrow network channel. If you can saturate the channel, and don't leave any gaps, what's the performance difference if the data comes from a single query or many that are back-to-back. The data is transferred to the client either way. Both Firebase databases are pipelined, so this "many round trip" argument is not a decent argument if the client can issue the queries without waiting for responses (such as the code in this article).

The other is consistency levels and correctness. I constantly see devs call Firebase an eventually consistent database which is wrong, its causally consistent [1], and this makes a huge difference when trying to do OLTP. The offline capabilities are built on the consistency primitives, and it's the only way it can work. So while this convex article is banging on about "End-to-End Correctness Philosophy", they miss the most important quality of correctness, and if they are not careful, will miss the required engineering, and then be unable to deliver an offline cache over real-time streams. I see this playing out with Supabase, I warned them personally before they got into YCombinator that what they were building was not causally consistent. Since then, they have had to rearchitect their real-time features after shipping them. (I have not reviewed their latest design yet so I have no idea whether they have it right yet).

Many things sucked about Firebase. The bespoke security rules and the lack of views. So Convex is on the money shipping functions on the backend. I think Supabase is shipping competitors' mistakes with row-level security language. Personally, I think Firebase's mistakes can be fixed with the addition of an open-source Firebase server [1], as the clients are already open source and the mistakes are all to do with just the server. The real tech was always in the clients anyway (offline cache, connection management, operation queues).

It will be interesting to see if building expressly for React is a good idea. Firebase shipped many adapters, like https://github.com/FirebaseExtended/reactfire, using the "thin-waist" principle of not over-fitting. But Javascript technology moved from callbacks to async while Firebase was in the field, so the current API is not now idiomatic. But convex is setting itself for even more ecosystem fragility, what if React changes API or falls out of favor? This is a big risk! I hope they can roll with whatever happens!

[1] https://observablehq.com/@tomlarkworthy/redis-backend-1

Re: Convex vs. Firebase

#8

Post by alexcole »

DanielKehoe wrote: post #3

I'm more interested in a comparison of Convex to Supabase. Any thoughts?

Author here! I think the comparison between Convex and Supabase is quite similar to Convex vs. Firebase! Supabase also encourages developers to load individual SQL queries from the client, supports edge functions without having a reactivity story for them, etc. Superbase is designed to be a Firebase alternative and appears to be taking most of their high-level approach.

Re: Convex vs. Firebase

#10

Post by alexcole »

rockwotj wrote: post #2

Firestore does provide global consistency, so the following quote is incorrect: > In Cloud Firestore, the data on the client are loaded from the database at different points in time. Even if you listen for realtime updates, results from separate queries will not remain in sync. This creates consistency anomalies and bugs in your app. Here is a link to the protocol documentation that the clients use to support it: htt…

Thanks for the pointer! I'll update the article to be more accurate!
Post reply on HN