How long is the beta waitlist at this time?
Convex vs. Firebase
71–80 of 85 posts
Re: Convex vs. Firebase
#72How long is the beta waitlist at this time?
Very short! We're trying to get beta keys to all of you today! :)
Re: Convex vs. Firebase
#73Earlier quoted context omitted.
Why would a SQL query show stale data? Inserts and selects are fine, the only thing needed is signaling. You can use Firestore for that, or just a separate thin layer on a much more capable database backend. > "that few development teams have the skill" This is the fundamental problem. There's no magic answer to a lack of skill.
Because the way that you will ultimately have to scale something like PostgreSQL for example is going to end up with eventual consistency which Firestore doesn’t have to deal with.
There's no reason for eventual consistency. Firestore is backed by BigTable and Spanner (both strongly consistent just like Postgresql). There's nothing magic about this - it just provide a pub/sub channel on the watched keys and automatically does a SELECT loop in the background once an INSERT triggers that key.
You can do the same thing on a simple by selecting by a `chatid` in a table that'll get the latest messages/inserts. Again, the only thing needed is the pub/sub layer, not an entirely different database.
Re: Convex vs. Firebase
#74Re: Convex vs. Firebase
#75The 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?)
(I work at Convex)
I was the one of the original TLs of Google Photos, specifically on Android and eventually managed all of the frontend teams for Google Photos. So I hope it's not a stretch to say that I have deep empathy for frontend problems. We also have great frontend oriented folks on the team.
I also worked with jamwt at a previous company (Bump) doing frontend work. When we worked together, I remember the acceleration of our ability to execute when the backend people were closely involved in our data syncing problems. Heck jamwt and team even wrote most of the initial client syncing code. When backend and frontend folks work closely together to solve data problems you can make magical things happen. In the end we're just product oriented engineers trying to ship delightful experiences.
Re: Convex vs. Firebase
#76Earlier quoted context omitted.
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.
Neat. The rpc to Postgres seems really cool. How does it scale compared to firebase (do you have to think too much or just implement and move on)?
Re: Convex vs. Firebase
#77Earlier 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…
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 an…
I use Firestore. I think your analysis is spot on. It is great for OLTP workloads. For query/analysis, you'll need to replicate to another database.
another area where it truly shines is zero downtime for schema updates.
Re: Convex vs. Firebase
#78I 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 g…
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.
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.
Re: Convex vs. Firebase
#79According 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…
Great list! I think we've had similar frustrations with firestore.
#3 is not really correct. You can sort on any single field but if you have multiple fields, then yes, you must create an index.
#4 I partially agree. The web dashboard makes things I don't want to do (accidentally edit or delete a field/document) dangerously easy, and things I do want to do (copy the contents of a document, save the results of a query, copy the text of a field) exceedingly difficult. The truth is that firestore is geared toward people who want an easy way to get near real-time data synchronization. It really sacrifices almost everything else.
The number one most annoying thing to do with firestore is work with their security rules.
Re: Convex vs. Firebase
#80Earlier quoted context omitted.
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
And RPC functions: https://supabase.com/docs/reference/javascript/rpc