22 ms·

Convex vs. Firebase

111 points by alexcole 4y ago

rockwotj 4y ago
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/d0b394f188e8c308438e5610d77ba51bb4bcb053/google/firestore/v1/firestore.proto#L852 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
- alexcole 4y ago
  Thanks for the pointer! I'll update the article to be more accurate!
DanielKehoe 4y ago
I'm more interested in a comparison of Convex to Supabase. Any thoughts?
- alexcole 4y ago
  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.
  - ajdegol 4y ago
    you can put that on the server with postgres views in supabase
    - kiwicopple 4y ago
      And RPC functions: https://supabase.com/docs/reference/javascript/rpc https://supabase.com/docs/reference/javascript/rpc
- VinLucero 4y ago
  +1. Also interested in this comparison!
rockwotj 4y ago
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 https://news.ycombinator.com/item?id=26910411
- james_cowling 4y ago
  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.
  - pyinstallwoes 4y ago
    In the end everything is a kernel poll. Haha
    - jamwt 4y ago
      Yep and every lock is a spinlock. ;-)
  - jitl 4y ago
    how does your query invalidation work internally?
    - james_cowling 4y ago
      We track the readset for any active subscription. When a new write transaction commits we compare the writeset for the transaction against any active subscriptions. If there's an intersection then it's likely that query will have been invalidated, so we rerun it. I talk more about how we perform this comparison in this (now rather outdated) talk: https://youtu.be/iizcidmSwJ4?t=1218 https://youtu.be/iizcidmSwJ4?t=1218 Note that there are false-positives here, i.e., it's possible for the inputs to a query function to change without the outputs actually changing, but this is not a significant issue in practice.
TekMol 4y ago
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.
- duxup 4y ago
  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.
- okhobb 4y ago
  This is a strawman and no one would actually design a messaging app using a NoSQL db like that. Typically one would employ a strategy to fan-out data such that the message document has everything needed to render a message in the UI.
- danielvaughn 4y ago
  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.
tlarkworthy 4y ago
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 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 https://observablehq.com/@tomlarkworthy/redis-backend-1
flax 4y ago
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.
pbreit 4y ago
All I want is an easy to deploy to stack with a database. What should I try?
- fragmede 4y ago
  It's impossible to give a proper recommendation without additional details but Firebase will do just fine. There are tons of YouTube tutorials and Medium posts about how to do that.
- jitl 4y ago
  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.
aboodman 4y ago
I don't get it. Firebase has functions as a first class citizen: https://firebase.google.com/products/functions https://firebase.google.com/products/functions
- aboodman 4y ago
  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.
- alexcole 4y ago
  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.
- tlarkworthy 4y ago
  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.
RayVR 4y ago
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/functions#query-functions https://docs.convex.dev/understanding/convex-fundamentals/fu...
- boloust 4y ago
  The results of Convex functions are cached, which means they only need to be recomputed when the data they rely on changes. This is by no means a panacea, but it does result in different performance characteristics than one might expect.
  - RayVR 4y ago
    They may be cached, but if the underlying data changes, which seems likely in the messages example, it looks like the entire query has to run again.
_vvhw 4y ago
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 https://pmg.csail.mit.edu/papers/vr-revisited.pdf [2] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/ https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama... [3] https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine https://dropbox.tech/infrastructure/rewriting-the-heart-of-o... [4] https://www.oreilly.com/library/view/velocity-conference-new/9781491928011/video228681.html https://www.oreilly.com/library/view/velocity-conference-new...
- rmbyrro 4y ago
  Dropbox is one of the subscriptions I'm most glad of paying.
- jmkni 4y ago
  Fun fact, Barbara Liskov is the L in SOLID
  - _vvhw 4y ago
    And coined the term “killer heuristic” for chess algorithms.
- swyx 4y ago
  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?)
duxup 4y ago
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...
uptown 4y ago
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.
spankalee 4y ago
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.
fragile_frogs 4y ago
Convex queries remind me of RethinkDB's query language (ReQL). RethinkDB also had the horizon project[0], looking at todays projects like Convex, Thin[1] and supabase[2], kinda makes me wonder what the RethinkDB guys could have build. RethinkDB was such a great project. [0] https://rethinkdb.com/blog/horizon-release https://rethinkdb.com/blog/horizon-release [1] https://thin.dev/ https://thin.dev/ [2] https://supabase.com https://supabase.com
- _query 4y ago
  Hey, Founder of Thin here. Thanks for mentioning us :) On RethinkDB: The post-mortem of RethinkDB is a good read https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm... If anyone has questions regarding Thin I'm happy to answer.
duval 4y ago
How long is the beta waitlist at this time?
- alexcole 4y ago
  Very short! We're trying to get beta keys to all of you today! :)
  - duval 4y ago
    Thank you. Invite received!

111 points by alexcole 4y ago

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/d0b394f188e8c308438e5610d77ba51bb4bcb053/google/firestore/v1/firestore.proto#L852 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

alexcole 4y ago
Thanks for the pointer! I'll update the article to be more accurate!

DanielKehoe 4y ago

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

alexcole 4y ago
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.
- ajdegol 4y ago
  you can put that on the server with postgres views in supabase
  - kiwicopple 4y ago
    And RPC functions: https://supabase.com/docs/reference/javascript/rpc https://supabase.com/docs/reference/javascript/rpc
VinLucero 4y ago
+1. Also interested in this comparison!

rockwotj 4y ago

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 https://news.ycombinator.com/item?id=26910411

james_cowling 4y ago
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.
- pyinstallwoes 4y ago
  In the end everything is a kernel poll. Haha
  - jamwt 4y ago
    Yep and every lock is a spinlock. ;-)
- jitl 4y ago
  how does your query invalidation work internally?
  - james_cowling 4y ago
    We track the readset for any active subscription. When a new write transaction commits we compare the writeset for the transaction against any active subscriptions. If there's an intersection then it's likely that query will have been invalidated, so we rerun it. I talk more about how we perform this comparison in this (now rather outdated) talk: https://youtu.be/iizcidmSwJ4?t=1218 https://youtu.be/iizcidmSwJ4?t=1218 Note that there are false-positives here, i.e., it's possible for the inputs to a query function to change without the outputs actually changing, but this is not a significant issue in practice.

TekMol 4y ago

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.

duxup 4y ago
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.
okhobb 4y ago
This is a strawman and no one would actually design a messaging app using a NoSQL db like that. Typically one would employ a strategy to fan-out data such that the message document has everything needed to render a message in the UI.
danielvaughn 4y ago
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.

tlarkworthy 4y ago

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 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 https://observablehq.com/@tomlarkworthy/redis-backend-1

flax 4y ago

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.

pbreit 4y ago

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

fragmede 4y ago
It's impossible to give a proper recommendation without additional details but Firebase will do just fine. There are tons of YouTube tutorials and Medium posts about how to do that.
jitl 4y ago
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.

aboodman 4y ago

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

aboodman 4y ago
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.
alexcole 4y ago
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.
tlarkworthy 4y ago
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.

RayVR 4y ago

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/functions#query-functions https://docs.convex.dev/understanding/convex-fundamentals/fu...

boloust 4y ago
The results of Convex functions are cached, which means they only need to be recomputed when the data they rely on changes. This is by no means a panacea, but it does result in different performance characteristics than one might expect.
- RayVR 4y ago
  They may be cached, but if the underlying data changes, which seems likely in the messages example, it looks like the entire query has to run again.

_vvhw 4y ago

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 https://pmg.csail.mit.edu/papers/vr-revisited.pdf [2] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/ https://www.wired.com/2016/03/epic-story-dropboxs-exodus-ama... [3] https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine https://dropbox.tech/infrastructure/rewriting-the-heart-of-o... [4] https://www.oreilly.com/library/view/velocity-conference-new/9781491928011/video228681.html https://www.oreilly.com/library/view/velocity-conference-new...

rmbyrro 4y ago
Dropbox is one of the subscriptions I'm most glad of paying.
jmkni 4y ago
Fun fact, Barbara Liskov is the L in SOLID
- _vvhw 4y ago
  And coined the term “killer heuristic” for chess algorithms.
swyx 4y ago
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?)

duxup 4y ago

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

uptown 4y ago

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.

spankalee 4y ago

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.

fragile_frogs 4y ago

Convex queries remind me of RethinkDB's query language (ReQL). RethinkDB also had the horizon project[0], looking at todays projects like Convex, Thin[1] and supabase[2], kinda makes me wonder what the RethinkDB guys could have build. RethinkDB was such a great project. [0] https://rethinkdb.com/blog/horizon-release https://rethinkdb.com/blog/horizon-release [1] https://thin.dev/ https://thin.dev/ [2] https://supabase.com https://supabase.com

_query 4y ago
Hey, Founder of Thin here. Thanks for mentioning us :) On RethinkDB: The post-mortem of RethinkDB is a good read https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm... If anyone has questions regarding Thin I'm happy to answer.

duval 4y ago

How long is the beta waitlist at this time?

alexcole 4y ago
Very short! We're trying to get beta keys to all of you today! :)
- duval 4y ago
  Thank you. Invite received!