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

11–20 of 85 posts

Re: Convex vs. Firebase

#11

Post by danielvaughn »

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 querying is nearly worthless.

2) The database design strongly pushes you towards nesting collections, making side effects cleanup a disaster, especially as a database grows in complexity.

3) You cannot sort on a field without creating an index first. I get why creating an index is a good idea, but I can't even write a simple analytics script without indexing the fields first.

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

5) The recommended development approach is to directly query the DB from the frontend, with no server in between. This means any data security has to be implemented in a separate DB rules document. The syntax and structure of this doc is super limited and often results in a giant, unmaintainable file.

6) Firestore cannot count. As in, you literally cannot query the number of records in a collection. If you want that value, you have to store it as a separate field in the collection, and then update that value each time you add and remove a doc. MADNESS.

I could go on, and on, and on.

Re: Convex vs. Firebase

#12

Post by sujayakar »

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…

hi! sujay from convex here. I remember reading about your "reverse query engine" when we were getting started last year and really liking that framing of the broadcast problem here.

as james mentions, we entirely re-run the javascript function whenever we detect any of its inputs change. incrementality at this layer would be very difficult, since we're dealing with a general purpose programming language. also, since we fully sandbox and determinize these javascript "queries," the majority of the cost is in accessing the database.

eventually, I'd like to explore "reverse query execution" on the boundary between javascript and the underlying data using an approach like differential dataflow [1]. the materialize folks [2] have made a lot of progress applying it for OLAP and readyset [3] is using similar techniques for OLTP.

[1] https://github.com/TimelyDataflow/differential-dataflow

[2] https://materialize.com/

[3] https://readyset.io/

Re: Convex vs. Firebase

#13

Post by james_cowling »

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 can lead to high page load times for many web apps.

Consistency-wise Convex supports full serializability. The main point this article is making with regards to consistency however is providing tools to ensure not only that the database is consistent but that the data rendered to the end user is also a consistent view. I talk a little more about that here: https://youtu.be/B9aeddqwVas?t=446

Btw we are huge fans of Firebase and think it did a ton to advance the industry forward. Thanks for your work on it!

Re: Convex vs. Firebase

#14

Post by flax »

While I like the idea of reactive server side queries, the focus on React and Javascript/Typescript really turns me off.

I use Flutter for my front end, and I simply haven't had any of the trouble they say people are having with Firebase and React. Perhaps the problem is not the Firebase half of that combo.

I do use Typescript for Cloud Functions in Firebase and it IS slower than manipulating documents directly. I'd love having a more responsive mutation path with server-side business logic. But I'd love it more if I didn't have to write it in JS/TS.

Re: Convex vs. Firebase

#15

Post by habosa »

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…

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 not make a new HTTP connection per request. It uses a long-lived gRPC connection.

Re: Convex vs. Firebase

#16

Post by mquander »

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…

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.

Re: Convex vs. Firebase

#17

Post by danielvaughn »

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.

Same. I find myself wishing we were on Mongo, it's that bad.

Re: Convex vs. Firebase

#18

Post by ceeplusplus »

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

Re: Convex vs. Firebase

#20

Post by danielvaughn »

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.

Yep. And what’s worse is that Firestore is notoriously difficult to migrate away from (at least from what I’ve heard, haven’t yet tried it myself). So if you take the prototype and turn it into an mvp, you’re kinda stuck with it.

If the goal is to create a prototyping DB, ideally there’d be some nice off ramping or migration tools for when the app needs to become production ready.

Post reply on HN