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

61–70 of 85 posts

Re: Convex vs. Firebase

#61

Post by james_cowling »

_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…

Thank you! We have a really talented team working with us but we're very actively growing. If anyone is looking for a job in San Francisco: https://www.convex.dev/jobs

Re: Convex vs. Firebase

#62

Post by james_cowling »

jitl wrote: post #45
james_cowling wrote: post #5

Earlier quoted context omitted.

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.

how does your query invalidation work internally?

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

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.

Re: Convex vs. Firebase

#63

Post by jamwt »

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?)

(Founder / CEO of Convex here)

Hi Shawn. I don't remember you bringing this up when we spoke in person recently, but it's a great question.

In our opinion, the very best way to evaluate yourself as a backend developer is how directly you solve problems for frontend developers. We believe in the merit of customer obsession, and the customers are not buying queues. They're buying the product as they see it: its surfaces, workflows and experience. And that's what the frontend developers, PMs, and designers are creating.

Historically, all these backend technologies that only interoperate with each other are only useful so long as they make product creation and improvement easier, more reliable, etc. We strongly believe as soon as you don't need them anymore, you should toss them out. They're complex and not proprietary to your product.

Convex (and serverless in general) is just the next step in providing more powerful abstractions that allow companies to double down on frontend engineering (work that adds product value) instead of reimplementing the same backend/devops plumbing the users never see (work that, at best, merely sustain product value).

So, given that we recognize this need, I respectfully disagree that we're not well equipped to solve these problems for frontend developers! Most of our team's recent our work has been designing synchronization and storage platforms to enable product development, including work on web, desktop, and mobile libraries/SDKs. We feel like we have both a lot of empathy and experience for this space, and we're very proud of our early product and the enthusiasm from the web dev community.

Re: Convex vs. Firebase

#64

Post by stickfigure »

danielvaughn wrote: post #51
lowwave wrote: post #34

Earlier quoted context omitted.

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

This is not correct. You can filter on the same field twice. What you can't do is filter on different fields, eg:

I want records where record.score >= 10 and record.date

The first form (single field) is a simple range query on a single index - that's what Firestore is optimized for. The second form (with different fields) potentially requires walking the near-entirety of both indexes looking for matches, and therefore has unbounded time and computational requirements.

Firestore is designed so that you can't do things that don't scale. Sometimes that sucks, especially when you know that the data volume for that query will always be "reasonable". But the limitations are not arbitrary.

Re: Convex vs. Firebase

#65

Post by manigandham »

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…

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.

Re: Convex vs. Firebase

#66

Post by jamwt »

pyinstallwoes wrote: post #32
james_cowling wrote: post #5

Earlier quoted context omitted.

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.

In the end everything is a kernel poll. Haha

Yep and every lock is a spinlock. ;-)

Re: Convex vs. Firebase

#67

Post by fragile_frogs »

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

[1] https://thin.dev/

[2] https://supabase.com

Re: Convex vs. Firebase

#68

Post by danielvaughn »

stickfigure wrote: post #64
danielvaughn wrote: post #51

Earlier quoted context omitted.

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.

This is not correct. You can filter on the same field twice. What you can't do is filter on different fields, eg: I want records where record.score >= 10 and record.date The first form (single field) is a simple range query on a single index - that's what Firestore is optimized for. The second form (with different fields) potentially requires walking the near-entirety of both indexes looking for matches, and therefor…

I never assumed they were arbitrary, it's more that they don't fit the product. This DB architecture fits some use cases, I'm sure, but the decision should be made by an experienced person. In the real world, what happens is that early stage startups get hooked on the whole "fast and scalable prototype" marketing copy, then hire some FE devs that build the entire app on Firestore because they don't know any better. 99 times out of 100, a startup's use case is not going to be a good fit for Firestore, but Firebase has no vested interest in informing the customer about this little detail. I've only worked with Firebase for 1 year and I've now seen this exact situation happen 3-5 times.

Re: Convex vs. Firebase

#69

Post by mhoad »

manigandham wrote: post #65
stillkicking wrote: post #38

Earlier quoted context omitted.

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

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.

Re: Convex vs. Firebase

#70

Post by _query »

fragile_frogs wrote: post #67

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 [1] https://thin.dev/ [2] https://supabase.com

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

If anyone has questions regarding Thin I'm happy to answer.

Post reply on HN