What is Convex & Why Should Developers Care?

What is convex? It's database functions and sync. Okay, thanks for watching. Please like and subscribe. Until next time, cheerio. Wait, what? What? What's that? You want more details? Uh, you're probably right. I probably should elaborate just a touch more given that the what is convex question is a question that I get probably the most frequently from people. So, that's what we're going to explore in this video. I'm going to go through the three top things that make convex well convex. Oh, and you're definitely going to want to stick around to the end because I'm going to do something that I probably shouldn't do. I'm going to give you several reasons why you might not want to use convex for your next project. All right, so grab yourself a lovely cup of tea and let's get started. Okay, before I dive too far into the details, I think it's going to be important for us to take a highle view of what makes up an app in 2025. So, we start off with our clients down here, and this is what your users are generally going to interact with uh in your application. Then, beyond very simple applications, you're going to need a way to share some data between those clients. So, you could do that peer-to-peer, but that's going to be kind of limited in the type of applications that you're going to be able to build. Um, generally you're going to want a server in the middle that mediates access to the database and allows you to share the data between the different clients. And while we're at it, we're probably going to want to access some third party services like AI or email or payments or things like that. So this part right here, this is Convex. It's the server and the database. It doesn't do this part down here where we're hosting your client or your website. That's still done by yourself through a service like Netlefi or Versel, though Convex does have file storage, so you could potentially do it, but um it's not recommended. Now, I know this is pretty simple, but I think it probably makes up about 95% of the apps that you or I are likely to be building in 2025. Okay, so now you have the overview. Here are the three crucial things you need to get Convex. One, the database. two functions and three sync. Let's go into each one of those in more detail. Now the first thing you should think about when you think about convex is the database. It's a bit like a document database like fire store or MongoDB but has relational properties a bit like Postgress or MySQL. So you can put documents into it with any old schema much like a traditional document database. But in my opinion, you you really missing out on a lot of the power of convex if you do that. Instead, what you want to be doing is defining a schema up front like this. So what we have here is a strongly typed schema much like Postgress. We have a users table, post table, and comments table. You can define fields on the tables using this v. syntax from the convex/v values library. And it works very similar to Zord if you're familiar with that one. And just like other relation databases, we can define relationships between tables using this V do ID syntax. So at this point you're probably thinking, so what? It's just another way of writing relational databases. No big deal. So to illustrate why I think this isn't true and why I think Convex really does nail the database, let's take a look at the schema again. Now we have our users, posts, and comments, which is nice. And if we just focus on the posts for now, let's have a look at what it would look like as an SQL schema. Right now we are assuming that posts are just text posts. Um they have this content field right here which is going to hold our text content. But what happens if our boss came to you and said, "Ah, actually we want more than just text posts. We want video posts too or link posts or something else." So if this was Postgress, how would you do it? Um, one way it could be done, I suppose, is to add another field to the post table. Um, this video URL field here. But now we have basically merge two concepts, two entity types into one table. So, we'd have to set this content as nullable um because maybe it's not there in the context of video posts. This would work, but you can imagine this would getting rather messy as we get different kinds of posts. Another way we could approach it is we could have two completely separate tables. We'd have this text post table here and this video post table here. But now we have to maintain two separate tables. And it gets messy if we want to query all the posts regardless of what kind of post it is. What we really want is a TypeScript like union type like this. If we had this, it would allow us to create posts that are either text posts or video posts with like clear separated types for each while still able to treat them as a post type. And we can't do this in Postgress unfortunately, but we can do this with convex. So here we can see we have our union of objects where each of these two options has a literal kind of either text or video. And if you squint a little bit, it looks almost exactly like our TypeScript type, which is awesome as it gives us much more flexibility on the shape of our data as requirements change, which they inevitably do. All right, so you now know what the database is in convex. I think we should now explore what I think is the second most important thing you should think about when you think convex. That is the server or functions. So, Convex is also a function compute platform like AWS Lambda, Google Cloud Functions or Superbase Functions or any of the countless options for this these days. So, let's say you wanted to do some sort of call to an LLM like OpenAI or something. The way you would do this is to write an action inside of a convex directory. So, this would be pretty familiar to anyone who's done any kind of server function before. One thing to point out is that we're using our runtime type validation stuff here in the args to validate the shape of the data that we expect to go into this function. So if the client passes us bad data, convex is going to reject it before running our handler. So once that handle has done its business, it can just return the result for us. Now if that was all there was to convex functions, it would be pretty great. But it's not. There's actually two more function types that we can define other than action and they are kind of special. So you see up to now I haven't mentioned how we actually access or modify the data that's stored in our convex database. We actually do that through these two special function types queries and mutations. Let's have a look. So you can see here it's syntactically quite simple. So we have a get post function here that takes a post ID and it looks up into DB um the post and returns it. Then we have this update content mutation that takes a post ID and some content and updates it in the database. It's pretty easy, nice and clean. But you're probably wondering why does Convex have three different types of functions: actions, queries, and mutations. Other server function platforms only need one. So why why does Convex have three? The key thing to realize about queries and mutations is they are actually very different from actions in that they are transactional and effectively live inside the database much like store store procedures from the relational database world. What this means is that a convex mutation can entirely succeed or entirely fail. To explain what I mean, let's take a look at this mutation here. We can see that we're doing an update to the database in the first part. Then we're doing a lookup in the middle here. And if that passes a final update here at the end and if this is a traditional lambda function then our data could quite easily become corrupted here as we've entered this partially updated state. But with convex if any of this part this mutation here fails all the changes get rolled back. So we never end up in a state where the content is updated but the last modified value isn't. So this is what I mean by it's being transactional. It's either all or nothing. And this is a huge advantage because it means we don't need to worry about race conditions or partial updates if multiple users try to modify the data at the same time. Convex just handles all of that complexity for us. And because these functions live inside the database, they're incredibly fast. There's no network round trip between application server and the database server. All right, so the third and final piece of the puzzle here is the data syncing. This was probably one of the biggest selling points of convex to me when I first heard about it and was certainly the thing that attracted my attention. So let's take a little look how clients in this case a React application might call our convex functions. So when we click the button here, it's going to call our update post mutation. The mutation is going to update the database and note our UI instantaneously updates. Note that nowhere here do I manually need to flag that any data is dirty. Convex just automatically knows that this change will affect this query here and thus force it to rerun and update the client. The bonus thing about queries being deterministic like this is that they can be cached so that when we refresh the page like this, we can see in the logs in the in the Convex dashboard that this function was cached. So it instantaneously returns. And it gets even better than this. So what happens instead of just returning one document, we want to return all documents that match a specific query. So this query is going to return all posts where the author ID matches the user ID that we pass in. Um, and the really cool thing about this is that Convex will automatically keep this list up to date for us. So you can kind of think of this as like a live query that's constantly going to be updated. So if another user in the application creates a post or updates a post and it matches our filter, then our component here is going to automatically update and we just don't need to manually keep track of that ourselves. And just like before on our client side, it's as simple as this using the use query hook. So this way of splitting your applications logic down into actions, queries, and mutations is beneficial on multiple levels. Not only does it allow for like really elegant syncing and caching features, I think it also allows you to create really nice delimination separation inside your application. So your effectual code goes into actions and your database modifying or querying code goes into mutations and queries. So if you're only going to take one thing away from this video, let it be this. Convex is a way of building your app that encourages clean and maintainable code. By removing many of the foot guns that come along with spaghetti code, you can be more confident the project will last and will be easily understood in the future by you or AI. Okay, so this one's a bit of a bonus topic, but let's quickly talk about components as they are relatively new addition to Convex, but I haven't seen anything like them before and I think they are really truly special. So what are they? Well, you can kind of think of them as like little Convex applications embedded right within your application. Each component can have its own actions, queries, and mutations, and it's given its own little private database. So the closest analogy I can kind of think of is like a WordPress plug-in, but unlike WordPress plugins that share the same database, in Convex, each component's database is namespaced. So this means that neither you nor the component can access each other's data directly. All interactions must go through an API layer. So let's take a look at some of the components that Convex currently offers. So, as of filming, there are currently 22 components that range from libraries that assist with AI agents to ones that help with payments. Let's take a look at this one for example, the rate limiter. So, as you might expect, this one is going to allow us to define some rate limits. Uh how many messages can be sent within a given period, in this case, 10 per minute, uh with an allowance for a burst of three messages within quick succession. So we might use it like this. So here we have a convex mutation called send message that takes in a user ID and content of the message. Then in the handler we can call the limit function which is going to check if the users available rate limit tokens and if they have none left then it's going to throw an error. Otherwise it's going to insert the message into the database. And if we pop open the dashboard here, we can see that the data section has this little dropown where we can select our components namespace data and inspect it as we send the message. So here we can see the rate limit data changing. Similarly, if we go to the functions tab, we can see all the functions that the component defines. Very cool. So these are very much nice to haves. But when I personally think about convex, I think about it as a cohesive hole. So in addition to the database, function sync, and components, there's also a bunch more. So things like scheduled functions, which allow you to run code on a schedule. This is perfect for things like daily backups or sending reminder emails. Then we have file storage built right in, allowing you to store and serve files directly from Convex authentication. So, it has integrations with major or providers like or zero, clerk, but also has its own all solution if you want much more control. Search. I wish I had more time to cover this one cuz it's so cool. Um, but the database has full text search and vector search baked right in. And the great thing about it is that whenever something changes, just like with normal syncing of data, it also updates any any live search that's going on. Amazing. Self-hosted. So you can self-host the entire of Convex yourself if you like. It's got a very permissive license. So you don't need to have that vendor locking worry. You can just host it on your own hardware. So I did mention in the intro that I would also talk about things that Convex is not suited for. So based on what we've covered, I would say that Convex is great for the vast majority of web apps that people are going to be building these days and is absolutely perfect for apps that might benefit from real-time updates such as chat apps, collaborative document editors, apps that require scheduled background jobs or Chrome style tasks, multiplayer games with turn-based mechanics, and dashboards that need to reflect changes in real time. On the flip side though, it is important to highlight what use cases Convex might not be suitable for. So if you're looking to build highfrequency update applications or games such as firstperson shooters or real-time strategy games, it might not be suitable for that. Though I do have a video coming up where you can kind of fake high frequency updates so you can do features such as real-time cursors so long as you're willing to accept a little bit more latency in your application. So definitely make sure you subscribe to the channel if you want to see that video in the future. So another use case that convex might not be suitable for is when you're working with like massive amounts of data such as like an IoT sensor network or something where or maybe there's another use case might be if you're dealing with um you need like GPU resources for like AI training. So convex might not be the best suited um solution for that. Having said that, however, I found that when I've hit those sort of limitations, there's usually an easy work workaround for it. So, usually I can just call into a third party dedicated service and then just get the result back from that. And that way I get to keep convex as like the core of my application. I should also note here that comics does have some practical limits um around storage and compute resources that are worth considering if you are planning on doing a very large scale application. Um for example, there are caps on file storage and function execution times and things like that. However, for the vast majority of web applications built these days, I don't think those limitations are going to be an issue. They're certainly not for me. All right, so there you have it. That's what Convex is to me as of 2025 at least. And finally, I didn't mention this before, but I personally find that just building projects with Convex is just straight up fun. And I think this bit just gets lost these days with all the talk about vibe coding, but having really good code abstractions as well as well thoughtout APIs just makes building something a pleasurable experience. Okay, well that's it for me for now. I hope you enjoyed this video and if you did, don't forget to like and subscribe. And if you did like this video, maybe you should check out this video where I go into a project that I've recently built using the new OpenAI image model. It is kind of cool. So until next time, cheerio.