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

51–60 of 85 posts

Re: Convex vs. Firebase

#51

Post by danielvaughn »

lowwave wrote: post #34
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…

>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. that is probably a business decision. Google has api limites, so figures.

That's a good guess, but no this is a syntax limitation. For instance, if you wanted to say "I want records where record.score >= 10 and record.score <= 100", you can't do it, because you can't filter on the same field twice.

Re: Convex vs. Firebase

#52

Post by rowanG077 »

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…

I definitely would recomend keeping it server side if you don't need any other firebase features. You don't use firebase as a normal database. You use it for its realtime featureset.

Re: Convex vs. Firebase

#53

Post by swyx »

_vvhw wrote: 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…

i'm also equally impressed by their background, and puzzled that they choose to target frontend developers rather than backend developers (who presumably they would be much better able to solve problems for?)

Re: Convex vs. Firebase

#54

Post by ajdegol »

alexcole wrote: post #8
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.

you can put that on the server with postgres views in supabase

Re: Convex vs. Firebase

#55

Post by [deleted] »

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…

[deleted]

Re: Convex vs. Firebase

#56

Post by folkrav »

stillkicking wrote: post #38
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…

...and you will show your users stale data, which is a non-starter for a chat app. You will then need to implement some custom push/invalidate mechanism, based on a custom interpretation of the DB event log. The entire point of the Fire* style of database is that these trade-offs are not worth it in the long run, that few development teams have the skill and time to implement this themselves, and that databases can a…

You're on HN, where we still long for the "documents with links" days of yore.

Re: Convex vs. Firebase

#57

Post by spankalee »

I would hope that the authors know that you can run Firestore queries on the server just like Convex apparently can, either from Firebase/Google Cloud Functions, from Google Cloud Run, or from any other server.

Re: Convex vs. Firebase

#58

Post by stickfigure »

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…

Yes, these are all limitations. But the advantage that Firestore has is significant, and for some applications it's worth accepting those limitations:

* Firestore is truly a "fire and forget" datatabase that scales without effort or maintenance. If your app works for 500 users, it will work for 500 million. Without a devops staff.

Yes, Firestore (aka Cloud Datastore) feels crippled compared to running aggregations and joins on an RDBMS. If your data and load fit on a single node Postgres, by all means use it, that's a great solution! When your requirements exceed that, you're in a different world. You can look at Spanner ($$$) or its clones (operational load, maturity). Or you can do what I did, and run the firestore/datastore as a master database and replicate data to other stores (eg BigQuery) for analytics.

Firestore's sweet spots are very small (eg, you have many microservices and want simple cheap zero-maintenance persistence) or very large (where scaling and availability would give you headaches anyway). In the middle, traditional RDBMSes are great.

Re: Convex vs. Firebase

#59

Post by james_cowling »

swyx wrote: post #53
_vvhw wrote: 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…

i'm also equally impressed by their background, and puzzled that they choose to target frontend developers rather than backend developers (who presumably they would be much better able to solve problems for?)

This is very nice feedback. The short answer is that we want to solve problems that matter for the people who need them solved.

Re: Convex vs. Firebase

#60

Post by duxup »

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…

You can in fact create a server side query in Firebase if you wanted.

The fact that Firebase isn't using SQL is obvious and comes with up and downsides.

Post reply on HN