Curious about the choice to send requests with WebSocket connections instead of just plain old POST forms. This precludes anyone with javascript disabled from using any of these sites. I don't think there's anything in the business logic preventing it
You can use http directly for your functions [1]. Or you can create custom http actions [2]. We encourage websocket usage because it allows for reactivity and UI consistency and it plays nicely with reactive frontend frameworks like React etc.
HTTP handlers for requests can be defined, many Convex apps define these to handle webhook notifications and some apps consist primarily of these endpoints or app-specific REST APIs. (I work at Convex)
Well, I've only used convex for some hobby projects, and I must say; It allows me to build real-time applications without having to configure websockets, and it allows me to build applications pretty fast.
Did yall build all the database implementation components yourself, or are any of them open source / off the shelf? It sounds like Kafka could do the transaction log job, and overall the architecture sounds similar to XTDBv1 which does use Kafka for that component.
Convex cofounder here. Yep the database transaction logic, timestamp assignment, concurrency control, etc is all custom. This is a pretty key requirement in our ability to perform dynamic subscriptions and automatic caching in real time.
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.
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.
Since it’s really application specific (what rows should be soft deleted, is recovery possible…), you probably want to model these like any other state. With Convex you can do things like schedule a deletion mutation 30 days from now, or run a cron job that cleans up data out of retention.
I guess I'm just wishing for an insta-backend with a database layer that's auditable/temporal by default (like Datomic). Guess that's orthogonal to the problems you're solving.
This is kind of how Convex works under the hood, and so we might add more temporal/auditing functionality in the future (like a time-traveling debugger).
You could also implement this on top of Convex, if it makes sense for your write volume.
> Instead, we can check whether any of the writes between the begin timestamp and commit timestamp overlap with our transaction’s read set.
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.
Yes the readsets aren't based on lists of objects but rather the data ranges that a query touches, i.e., they don't suffer from phantom read anomalies.
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 a database for online workloads (ie, your users interact with your product via reading and writing data to the database) and are ok with writing your backend in JavaScript or TypeScript, you should consider Convex.
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).
How can we be sure you are going to be around when the inflation hits 9% and interest rates go up to 15% ? This is a serious question because whoever invests time in building on your backend which is not open source are taking extreme risks.
Could you please be more verbose about the licensing scheme and what it means for a company to decide to use Convex without the intention of paying right now?
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.
Convex is FSL licensed which means you can basically do whatever you want with it re running a service, other than directly competing with Convex, i.e., reselling the Convex platform. There are no limitations on you running a business on top of this and no obligation to pay anything.
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.
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.