31–40 of 85 posts
All I want is an easy to deploy to stack with a database. What should I try?
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.
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…
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.
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…
that is probably a business decision. Google has api limites, so figures.
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…
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.
It does provide a lot of serverless scalability for what it offers, but it's the classic case of optimizing for a situation that won't happen for 99% of their apps.
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…
I wish y'all the best I do think this is a super cool product!
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…
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 and should solve this for you.
I have little love for Cloud Firestore, it's a trash fire riddled with poor decisions, but if you don't even understand what the problem is with that SQL query, you don't understand the expectations users have nowadays of front-end applications.
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 g…
This is by no means a panacea, but it does result in different performance characteristics than one might expect.
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…
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 with firestore that works across all platforms. It scales well and works great for what it is.
If people try to use it in place of a rdbms or complex use cases, they’re going to have a bad time. But for those who can utilize their tool belt effectively, it’s awesome.
I love firebase products.