How Convex Works
stack.convex.dev
stack.convex.dev
The developer experience is really polished.
I haven't deployed any major apps yet, so unsure how the costs scale VS deploying your own or other BaaS offerings.
The team is incredibly skilled and great people.
[1] https://docs.convex.dev/http-api/#functions-api [2] https://docs.convex.dev/functions/http-actions
Edit: simultaneous post with my manager
https://v1-docs.xtdb.com/concepts/what-is-xtdb/
I’m also curious if you support unique constraints on non-id columns, or if having writer actions close to the database kind of takes that role.
It doesn’t use Kafka, the transaction logic is custom implemented in Rust.
Convex does not have special support for unique constraints, as they are easy to implement in your own code (like you wrote, the mutations are happening “inside” the database). This follows the philosophy of making it clear what the database primitives are, and hence what performance you can expect from the database.
Of course since your code is all JavaScript/TypeScript, it’s easy to layer in constraints via a library, like in https://labs.convex.dev/convex-ents/schema#unique-fields
Internally the very bottom of the stack on the hosted product is actually just a write ahead log on RDS and in the open source product it's just sqlite. We'll likely eventually build our own durable write ahead log, and have plenty of experience doing so, but this hasn't been needed so far.
2. Transactional by default - avoids concurrency bugs in production
3. End-to-end type safety, best-in-class TypeScript support for React and the backend
4. Explicit indexing for predictable backend performance in production (no unexpected deopts)
5. Super fast DevX: Save and have your code deployed. Flexible (optional) schema. Powerful reactive dashboard.
6. Feature-full: File storage, scheduling, text search, vector search all built in.
On the cons side: Auth story isn’t as streamlined as for Firebase or Supabase if you don’t want to use Clerk or Auth0. But we’re working on it!
Is this what you had in mind?
You could also implement this on top of Convex, if it makes sense for your write volume.
Do you handle the case where the actual objects don't overlap but result of an aggregate query is still affected? For instance a `count(*) where ..` query is affected by an insert.
If you were to attempt to fetch all items from an empty shopping cart, that query will automatically be invalidated if any item is added to the cart, even though there were no documents returned from the original query. Query intersection always works.
The aggregate example isn't a great one in Convex since it doesn't currently support built-in aggregates - a full-table aggregate involves a table scan and therefore the readset would be the entire index. We may add built-in aggregates that are incrementally computed if there's enough demand.
If you need for example peer-to-peer video or machine-learning inference, these are not well suited to building on Convex from scratch, but you can likely use Convex to implement the rest of the app (and probably use another service for these).
Since Convex is online and realtime, it doesn't focus on domains like embedded systems programming or analytics (but you can stream data from Convex to an analytics platform).
Convex is in a very comfortable financial position but it is also open source: https://github.com/get-convex/convex-backend
Supposing it is great, how business locked are you if you decide to use it?
For example, a corporation asks my company to build a fintech product that will be used by more than a million people in less than one year, we need to decide to use Convex or not, in the current licensing scheme how locked are we? Even if it's open source.
It is not that we don't want to pay for adding value to the whole product but there are a many options to choose.
After 2 years the code becomes Apache 2.0.
Note that if you're running the open source release you're on the hook for managing and scaling your own reliable infrastructure, as described in the open source readme.
I talk more about the philosophy re open sourcing convex in https://softwareengineeringdaily.com/2024/03/20/going-open-s...