Live data from Hacker News

Convex vs. Firebase

docs.convex.dev

41–50 of 85 posts

Re: Convex vs. Firebase

#41
post #33
post #15

Earlier quoted context omitted.

A few points here: 1) That’s a JOIN and Firestore is not unique among NoSQL databases for being bad at it. 2) That’s the code you’d use in a web browser to load Firestore data. That code also handles all of the API and Authentication code you’d normally put in front of another DB. It’s serverless. So that is a fully functional snippet, your SQL example needs an API layer and frontend deserialization code. 3) It does…

2: The code does not handle authentification. The code literally just says "Give me this, give me that...". 3: It is still a "a client-server http roundtrip" for every query. It does not open and close the http connection every time. But it sends a "GET / HTTP ..." request for every query. With hostname, accepted formats, encodings etc.

The code does not handle authentication because it does not need to - all data access and auth rules happen within Firestore/Firebase. If a client requests data they do not have access to, they won’t get it.

Re: Convex vs. Firebase

#42

Earlier quoted context omitted.

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.

Firestore makes it easy to get productive quickly and then drive straight into quicksand.

Re: Convex vs. Firebase

#43
post #30

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

Fun fact, Barbara Liskov is the L in SOLID

Re: Convex vs. Firebase

#44

Earlier quoted context omitted.

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.

Firestore makes it easy to get productive quickly and then drive straight into quicksand.

Couldn’t have said it better myself.

Re: Convex vs. Firebase

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

how does your query invalidation work internally?

Re: Convex vs. Firebase

#46
I love Firebase for what it provides "in the box". Auth, noSQL database, cloud functions a ton of added features like real time updates an a lot more. My use case is mostly for quickly developing personal, and "side apps" for work that complement our primary applications. It excels at that.

There's a lot of comparisons in here about querying in here those are fair-ish / true-ish, I do think that's also missing what Firebase is "about", at least that's not what I've found it useful for.

If you're thinking about weighty sever side business logic and SQL queries ... yeah Firebase isn't built around SQL, it's not built to optimize big business logic and SQL like queries (granted, there are still ways to do these things).

Firebase isn't likely replacement for your enterprise CRUD app that carries with it a ton of logic for each and every possible CRUD action. And you do have to stop and think about how you are going to structure your collections, docs and so on.

Having said that I think NOT being the solution for complex CRUD apps is what makes Firebase pretty great.

I think the idea that business logic on the server being kinda wonky on Firebase is true generally. At the same time:

"Once again, with Cloud Firestore you could put this code into Cloud Functions and use them as a business logic layer, but it's messy and requires giving up some of the platform's other features like reactivity and optimistic updates."

I think that statement is deceptively broad. Just using cloud functions doesn't eliminate optimistic updates and so on, the effect is limited to when or how you use them...

Re: Convex vs. Firebase

#47
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…

I mean if it's brevity you're after, the first example can be rewritten in a terser style:

    const userSnapshots = await Promise.all(
        getDocs(collection(db, "messages")).then(
            docs => docs().map(snapshot => getDoc(snapshot).data().creator)
        )
    )
Ultimately you're kinda just comparing preference for SQL syntax over JS in that case.

The JS example is also async (always adds visual complexity to code calls), whereas the PHP example is blocking. That SQL query doesn't look particularly efficient either...

There's plenty of good solid criticisms of Firebase & NoSQL but these aren't it. e.g. your HTTP roundtrip argument has been debunked by sibling commenters, but client-side DB calls is still riddled with adjacent problems & ultimately adding more complexity to the server-side avoid the need for client-side DB access is often worthwhile.

Re: Convex vs. Firebase

#48
post #19

All I want is an easy to deploy to stack with a database. What should I try?

I think Supabase is fine. At least you are writing security logic in Postgres instead of Cloud Firestore Authorization Language. Last time I tried the Cloud Firestore (2019) security language, it was by far the most complex part of the app, and the local simulator behavior diverged quite a bit. I expect the Postgres bits of Supabase will be reproducible locally without the Supabase bits.

Re: Convex vs. Firebase

#49
What's the go-to solution for mobile app user authentication? Is Firebase Authentication suitable / recommended?

Seems that Google has been flooded with Auth0 tutorials, but I'm wondering what alternatives mobile devs would recommend.

Re: Convex vs. Firebase

#50
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…

Most apps I build have a rdbms main data store but I use firestore for things like real time interactions or more recently real time commenting. It would be a bit more time consuming and challenging to set this up across iOS, android, and web. A lot more time would be spent figuring out the system to make this work well and without issues at scale. On the other hand… It takes like 20 min to set up a real time feature…

Check out Supabase, you can have your cake and eat it too.
Post reply on HN