Convex is a code-first backend platform that differs fundamentally from Supabase by expressing everything in pure TypeScript, including database schemas, queries, and APIs, rather than using SQL-based tables. Unlike Supabase where real-time functionality requires explicit subscription, Convex provides automatic real-time synchronization that guarantees apps always reflect changes to front-end code, backend code, and database state. Convex supports multiple deployment environments (production, development, preview, local) and requires developers to explicitly write functions for data access, making it particularly well-suited for real-time apps, prototypes, and dashboards requiring fast iteration and fewer backend setup steps.
Inmersión profunda
Prerrequisito
- No hay datos disponibles.
Próximos pasos
- No hay datos disponibles.
Inmersión profunda
This Finally Replaced Supabase for My Codex WorkflowAñadido:
While I love Superbase, especially when paired with no code builders that supported natively, your options expand dramatically once you start building real apps with AI agent coding tools such as codecs. This allows you to pair any backend you want because the agent can usually figure out how to connect it and make it work. One of the new backends I've been evaluating lately is Convex. It's a fast, easy to use backend with a generous free plan and it works especially well when paired with a Gentic app builders. And did I also mention that it's open source? And so in today's video, we'll explore what Convex is, how it works, and then build a real app with Codeex that uses Convex as its backend. Okay? And so if you head over to convex.dev, you're going to be here on this main page here, right? And and immediately it tells you that you're going to be building with confidence the backend building blocks for your agents. Okay?
So immediately if you are building your apps with codecs, cloud cord or any other agent that should get your attention. It definitely got mine.
Everything is code. Okay. From database schemas to queries from author APIs express every part of your backend in pure typescript. Okay. Now, this is an important piece right here because this is one of the main differences between something like Superbase and Convex.
There's lots and lots of differences that we're going to be talking about in today's video, but this right there is the first one in the sense that convex everything is code. When you create your data, you're just creating your data.
Everything else becomes code. With Superbase, that's not the case. You have your data. You also have your SQL statements. you have ways of getting that data. All of that is part of superbase, right? Because it's based on Postgress. Whereas convex is not based on po posgress. It's actually closer to Firebase. It kind of has this document structure where you create different documents, link them together, and then write code to access those documents.
And so it's a completely different paradigm compared to something like superbase. And next thing here is that always in sync. Okay, so convex libraries guarantee that your app always reflects changes to your front-end code, backend code and database state. And this is another big difference when it comes to convex and superbase. Now with superbase, you can enable real-time functionality to your existing tables.
It's a layer on top, right? When you create a table, it's a regular table that doesn't have real-time functionality. But to take advantage of that real-time functionality, you need to subscribe first, right? Your code needs to subscribe to receive those events. Here it's automatic, right? It's completely automatic. It's seamless. The code that is going to be accessing this data understands this, right? So you do not have to worry about enabling real time, you know, subscribing to events, stuff like that. And that is great when you want to build apps that rely on this real time in sync functionality, right?
Think about apps that are going to be accessed by multiple users. Think about something like a big Trello board that's going to be accessed by many employees and you know somebody moves that Trello card from one column to another that's got to reflect everywhere. Here you have some extra stuff like crown jobs you have off you have a lot of components that you can plug in. Now, unlike Superbase, Convex has a generous free tier, okay? And I'm going to show you what that means. And it's also open source, so you can always self-host it if you want. But what I'm going to do is I'm going to go ahead log in. I'm going to create a brand new account. And so, if we go over here, this is my account right here. I don't have any projects yet. We're going to create a project together. So, I'm just going to create a brand new project here. I'm going to click create. And a project works pretty much the same as in Superbase. almost the same, right? It's essentially an umbrella. It's a container for all the resources that may be tied to a specific app. And right there, it has created my project here. Okay? So, what do we have here on this main project dashboard?
First, we have our health here. We have our main kind of summary. If you click here, we have our data, right? And right now, I don't have any tables created.
Next, we have our functions here, right?
We don't have any functions deployed. We also have our files, right? So we can store data in here. We have our schedules for uh things like scheduled functions, cron jobs as well. Next we have logs and we also have settings here, right? Where I can configure various things, get the URLs and stuff like that. Now one of the more interesting things happens when you click on this menu over here, right? So when you click here, you can see that we have various deployments. Now deployments is a term that you're going to be hearing over and over. That is a big deal here in Convex. In fact, if you go back to Convex's homepage and click on pricing and scroll down, you can see that each plan has certain amount of deployments, right? And the free plan actually has lots and lots of deployments. There are 40 deployments, okay? Professional has more, but 40 is actually plenty when you're going to see what a deployment is. Okay? And so if we go back to our app over here, essentially what you're looking at here is a deployment, right? We have the production deployment. We have a development. We also have something called a preview deployment. And we also can have other deployments. Now, right here, I only have the production deployment. I can also create a development deployment. So I'm going to click here. And now it's going to go ahead and create a development deployment. Okay. So now I have two deployments inside this one project. Now you may be asking why would I need two deployments? Well, it's actually very very simple. When I'm building an app, I do not want to have just one environment, right? One deployment, right? I want to have multiple, you know, I I want to have a development, I may want to have a staging, I may want to have a production environment, right?
This is all very very important because I do not want to do something and have it available to all my users right away.
I want to test it out. I want to make sure that it works. And the same thing applies to your backend, right? Your backend needs multiple deployments, right? So we have a production, we have a development. Now we can we also have something called a preview, right? So if you click over here, you can learn more, right? Preview deployments are a simple way to automatically create a temporary deployment for each feature branch you create. These deployments are automatically cleaned up to 5 days. And so you may release a new feature and you want to test out that feature, right?
you want to maybe connect your app to that feature and just test out that feature. Well, in that case, you may want to create a preview deployment. And switching between deployments is super simple, right? I'm in development. I can go on production. I can go in here. And now I'm on the production deployment here. Now, in addition to all of these deployments, there's also another deployment that you can do. And this is a local deployment for development. And so instead of syncing code to a convex dev deployment hosted in the cloud, you can develop against a deployment running on your own computer, right? You can even use the convex dashboard with local deployments, right? So think about, you know, you're on the plane and you're building an app and you don't have internet access. Well, no problem. You can build an app hosted locally in codeex and connect to a local deployment. And this is something that's fairly tricky in other back-end systems.
Okay. So this is another big big benefit for using convex. Okay. So now let's go ahead and jump into our project here and let's go ahead and select an environment. So I'm going to select development. And now we can examine each feature one by one. And so by clicking on data I can see my tables here. So I don't have any tables. I'm going to go ahead and create a table. I'm just going to say table one here. I'm going to hit create. And now I have a table. So now it's telling me it is empty. I can add a document over here. And it wants me to to add a document here. So I'm going to go ahead and add a document. So let's say name James and city NYC. Okay. So I'm just going to do it using simple JSON over here. Hit save. And now I have here a document. Okay. And this document has an ID. It has a city. It has a name.
And it has a creation type. Okay. And I can double click. I can change all that.
Nate James. I can change all that. I can create a new table. So I can create, you know, table two for instance and create more documents. And then I also have some extra things that I can do such as a custom query, schema, indexes, metrics and all that. And so this is fairly straightforward. And like I said before, these tables are not really SQL tables, right? Convex is not a SQLbased backend.
These are more similar to Firebase's Firestorm. Now, moving right along right here, we have functions. Now, with functions, you can't really create them here directly. Okay, you can click this quick start guide, but what you really want to be doing is you want to have your AI agent creating all your functions for you. And same for data, right? And a little bit later in the video, I'm going to show you exactly how we're going to do all that. Next, we have files, followed by schedules, logs, and settings. So, now that we've gotten a basic overview of Codeex and how it works, let's go ahead and build a real app so that you can see how the data fills in and how all the pieces start to work together. And believe me, you haven't seen nothing yet. Once we build a real app, all of this is going to make a lot more sense. All right, so let's go ahead and put all of these things to the test. Let's go ahead and build a real app using Codeex and using Convex as our backend. All right. So, here I am in Codeex and I went ahead and created a new convoy here that's going to be used for this app and we're going to be running a series of prompts that over time we're going to build our app using Convex as the back end. Now, the app that we're going to be building is going to be a content calendar studio. And this is the first prompt that we're going to be using. built the first static version of content calendar studio with no backend, no AI, and no persistence. Here, I'm going to go ahead and add that it should do it in the demo one directory. Let's go ahead and execute this. And so, it doesn't have any questions for us. It has come up with a plan. Okay, this is our plan. And we're going to say yes, implement this plan. All right, so it has finished building our content calendar studio.
Okay, with sidebar nav, responsive mobile tabs, etc. And it has started a local server that we can click here and we can open up and see how the app looks. And look at this. Look at all of this. It has built. Look at this. We have this. We have this. We have all of these things here. And we're not using convex just yet. This is just a simple app. It's just purely UI. Okay. And so now let's go ahead and give it another prompt that's going to continue to develop this app. And I have this prompt over here. Improve the static content calendar studio screens. So they feel like a real internal creator ops tool.
Okay. Keep everything front end only with mock data. Do not add convex convex superbase anything. It's just, you know, builtin static data, right? Okay. Okay.
So, we're going to go ahead and run this. And another thing I told it is that keep the mock data centralized in one local data file or constant so it will be easy to replace with convex later. You see how I'm going in layers, right? I am kind of prepping it for our back end. But I want to make sure we get it right because it's it's a lot easier to get it right than to get it wrong and then spend a lot of time fixing it. And here it's telling us the current version has all mock data embedded in this file here. So I'm moving that into a dedicated local data file and then wiring filters and richer screen components against that single source.
Right, that's perfect. Now while Codex is running, this is a really good time to hit that like button, leave a comment, and support this channel so that I can keep it free of ads and other interruptions and just show you the good stuff. All right. So now it's actually testing this app in the browser. You see this cursor? That's not my cursor.
That's codeex testing. Okay. So let's see what happens. It's clicking around navigation and filters. And there it is.
That is the app. Looks really nice. Look at that. We have this pipeline by status. We have a production queue. We have priority focus. Let's see. New items. We have a new item. And nothing works yet. Just the UI. So now let's continue building by giving it another prompt and this time we're going to be getting closer to our convex integration. Now our next prompt is going to be inspect the existing content calendar studio app before editing. Do not change files yet. Return a concise convex integration plan. Okay. So, we want to see how it's going to be integrating this app to our convex backend, but not do it yet. Just give us a plan. Just give us an integration plan. Okay. So, I'm going to enter our plan mode, and I'm going to go ahead and execute that. All right. This is the plan. Integrate Convex around the smallest useful flow. Replace the content item list with live convex data.
Then allow one mutation from the existing UI to update a content item status. And here's the key part, right?
This is the data model. Use convex schema tables with indexes for the screen's current access patterns, right?
All of this ideas, queries, mutations, first vertical slice, replace only content items, first front end cleanup before convex, and our test plan. When I accepted the test plan, it started to actually wire it. Okay. And so ideally what happened here was that it gave me this plan and that was it. So when I accepted the plan it started moving forward. So it basically combined two steps into one. Okay. And so if I'm happy with this plan I can continue but I stopped it so that we can go step by step. So once we looked at this assuming it did not go forward. The next prompt I have here is to add convex to content calendar studio and replace the first mock data flow with real convex data.
And by the way, if we had run this previous prompt not in the plan mode, then it would simply output our schema and do nothing. And at that point, we would input this next prompt here, use the existing add convex to content calendar studio and replace the first mock data flow with real convex data.
Okay. So, let's go ahead and run this.
I'm just going to run it directly. And here, it's basically running to what it was doing before. Okay. And so, with plan mode, you're essentially getting two steps automatically, right? It's not just going to output the plan and do nothing. It gives you the plan, but then you can act on it. If we didn't run it in the plan mode, then it would simply output stuff and stop. And so, now it's continuing. It's installing convex. It's going to be adding the schema and functions, wire the React provider and all of that. And so when it finishes, we are going to go back to Convex and I'm going to show you what it has done because you're going to be amazed how our Convex dashboard is going to change from what it was to how it is now. All right. So it has implemented the convex vertical slice. And here it's telling us on one environment node npx convex codeg gen cannot yet run yet because this workspace has no convex development configured. Now we need to run this so it can finally connect to our convex account and establish that backend linkage. Okay. And so let's go ahead and sell it. So I'm going to select all this. I'm going to add all of that to chat. Run this. And now it should run all of that and hopefully connect to our convex project. All right. So I've connected this to my Convex account.
Okay. And so Convex is now running and wrote all of this and it has generated all of this. And if we go back into Convex, it actually created another account. This demo one. So if we go into demo one, this right here is what Codex is managing, right? This is a brand new account and that is going to be for the SAP. We have our data here. We have the content items. If you go into functions, we also have the functions. Okay. And so let's go ahead and wait for this to finish and then we're going to jump back and I'm going to explain what all of that really means. All right. So now it's verifying the app. It's verifying the UI. All right. So it ran all of this and completed setup. Convex is now configured for the app. Created Convex project demo one. All of this. And now is the moment of truth. Let's go back into Convex and let's see what happened there. Okay, because now our app is directly connected to our convex account. Okay, so this is my old project here and it actually created a new one.
So if we go in here, this is demo one.
And now let's take a look. So we have the content items table, right? This is our table. This is our data. And so if we go to our app, you can see that this should be the data, right? So like repurposing long form interviews into seven launch assets. It should be somewhere here. There it is. You see that? That's one of the items. And then newsletter. This is this is that newsletter here. And if we go into functions, you should be seeing functions. Now remember these functions are not built into convex. Codeex had to create them from scratch. Okay? Because convex gives us the data, but to access it, we need to write our own functions, right? And inside the functions, you can have your security policies and all of that. And so again, this is different from how Superbase does it. With Superbase, you have automatic access, you have API access, you have SDK access that is built into Superbase. With Convex, you need to write your own code to access it. Right? If you don't write the code, well, you can't access it. And here that is exactly what it is. So we have list, we have get, we have create, we have update, we have seed, right? So it created these functions so that our app works. And so if I select list and I click on run function this opens up we have the function input and we have the arguments and this is the output that it's going to be right because when you list that is the output here I can also act as a user right that's that's a good way you know to test different things if I click on let's say create and run function well guess what this these are going to be the arguments I have some other parameters to fill in and that is going to be the output right just for testing okay so it had to create them on its own otherwise there's no way to get that data and so this is another approach and honestly I like this approach I think it's really cool that you are explicitly forced to create your either queries you know readonly functions or mutators right functions that modify data so I think this is really cool and so at this point we have a really cool app look at this we have this thing that works and it changes things. We have owners. I can filter by owners. I can just take a look maybe Mia. There she is. Needs brief. I can filter by status. Here we have calendar view. We have content detail ideas board. So a nice content calendar studio that we have built. And for the last prompt, we're going to be pasting this.
We're going to copy that and we're going to paste this here. And the idea here is to expand convex integration across content calendar studio now that the f first vertical slice works. Keep the existing UI direction but replace the remaining key mock data areas with convex where practical. Okay, so we're going to go ahead and run this. In fact, why don't we just do it in plan mode to see what it has to say. And it's telling us content items are convexbacked for dashboard detail. calendar still intentionally uses mocked content. Ideas are still mocked, etc. So, this is going to hopefully bring convex throughout our app, right? Not just one slice. Okay, we're going to submit this. And as you've probably noticed, I'm using 5.5 Medium, and it has been just fine because this is a really, really simple app that we're building. It's a little bit more complex than a toudo app. In this case, I wouldn't have any issues using something like 5.5 Medium. And of course, if you were building something more complex with more complex logic with a lot more moving pieces, I would be using 5.5 high in this. All right.
So, it has finished building our expanded convex backed flow. And the best way to see the results is not by checking out the app. It's by actually going to convex and seeing what we have here. Okay. So, here we are back in convex. And if we go into data, we now have more tables. We have activity, we have ideas. If we go into functions, we have activity again. We have list by content item, right? Which is a relationship now. Okay, we have create seed for first content item. We also have another function here for content items. Cleanup test draft. And then we have the functions for this new ideas table list create move column and seed which is actually very very cool. And this means that our app has more features. Now even though we have a lot of functions we don't have any files just yet. We don't have any schedules and we should have some log information.
Right? Anytime you have an operation you're calling a function you're going to be seeing in our log section here.
Now, we're still in our development environment. If we hit if we go into production, we're not going to be seeing anything, right? Because we need to deploy all of that into the production environment, right? It's a completely separate environment. Okay? And same thing would happen if you're doing something like preview deployments, right? Or a local deployment. You need to move that data and that process is called migration. Okay? And so right now production doesn't have anything whereas our development has lots of things. So depending on where your app is connected to, right? So our app is connected to these cloud URLs, right? They're not connected to the productions, right? If you go to our production, it's content counter 165, but if we go to development, it's resoluterior 998, right? So if we point that to our production, it's not going to have any data, right? And that's by design. And this means you want to also have multiple development environment. And so that your production app points to this production environment whereas your development app points to the development environment. And that way when you're happy with how things look and behave on the development environment, right? Your code plus your data and your integration with convex.
Then you're going to create a migration to the production environment. And then the production app is going to have access to all of that new shiny things that you've implemented in development.
And so obviously this was a fairly simple app and I look forward to making more complex apps in the future. And if you want to see a more complex app that really tests everything that Convex has to offer, leave a comment below and I will do just that. And so some final thoughts here, right? So for codeex first app builders right what we are doing here we're building our apps with AA agents primarily codeex I would try convex earlier especially for real time apps prototypes dashboards right convex is the better fit when the app needs fast iteration realtime state preview dev environments and fewer backend setup steps okay superbase on the other hand is the better fit when your app needs postgress a SQL mature relational workflows or a backend your team already understands. And so when building apps, you're free to use any backend that you want. The question is which backend fits your workflow better. And as someone who's used Superbase for many, many years, Convex is a breath of fresh air.
It's It was a lot of fun using it and it works really really well and I actually look forward to using it in more projects.
Videos Relacionados
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
Re: 🗣️📍theprophedu📍2026 GST 103 CLASS (E-EXAM REVISION)
theprophedu
636 views•2026-06-04
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29











