Convex comes with setup complexity, especially for non-React developers, but after that offers a great UX with capacity to scale. Firebase is easy to set up and manage, but gets more complex when scaling.
I have created a todo app many times. What seems like something very simple can get complicated really quickly when you have to learn a new stack, build your own backend or think differently than you are used to.
TL;DR
Convex is extremely difficult to set up, especially for non-React users. The Authentication package ONLY works for React, and had to be written from scratch, which is a big negative. It is missing basic features and is overly complicated.
However, once Convex is properly set up for development and production, the actual developer experience is amazing and has a lot of potential for scaling a real noSQL app with fewer hurdles.
Firebase is easier to set up, manage and deploy, but the learning curve grows when you need to manage security and scaling. Convex is the opposite, due to the TypeScript first ecosystem.
Prerequisite ✅
I’m going to assume you have basic knowledge of Nuxt 4, Tailwind and Firebase. I’m going to focus on Convex.
What Is Convex?
Convex is a noSQL database platform that allows you to consume real-time data on the client in any form that you like. It does NOT allow true relational data, but you can query several documents at once, very close to the data itself, emulating a join.
Everything is written in TypeScript, so you don’t have to worry about complex security rules. Instead of trigger functions, you directly write your complexities inside the mutation itself, which lives on the Convex server. Authentication is sparse, but if you use Google or GitHub with React, you should have no problems.
What Is Firebase?
Firebase is a cloud platform with a noSQL database, authentication, security rules, cloud functions, etc. It is arguably the easiest database to learn, especially if you don’t need complex schemas or scaling. It has incredible querying capabilities for noSQL, second only to MongoDB.
Once you need tightened security, more complex data modeling or testing, the learning curve increases dramatically. It works out of the box in all frameworks.
Convex App Setup
Create a New Convex Project
Login to Convex and create a new project.
📝 Notice you have a production and development database by default.
📝 You also don’t have to worry about your free project auto-pausing, hence I have a demo below that can be free forever.
Create a Nuxt App
Install Tailwind
Don’t use the package. Follow the official Tailwind Guide.
Install Convex
I’m modifying the official Nuxt Convex Quickstart.
- Install the Convex Library once in your new project.
- Add the Convex URL.
- Set up a Convex dev deployment.
📝 This will be run in the background at all times to keep your app going.
You should see on .env.local variable:
- Set up Convex Auth.
📝 You may have to manually install @convex-dev/auth or @auth/core.
4b. (Optional)
I had to create this file. It could also be http.js if not there. Again, the auth setup is not intuitive and I ran into several issues.
- Set up GitHub
Log in to your GitHub. Then go to Settings → Developer Settings → OAuth Apps and create a new app.
Copy your secret key and client key. Remember to save your secret key, as you can never get it back!
📝 Your environment variables exist on the convex server, so these are NOT your app’s env variables!
- Define your tasks schema.
- Expose your database queries.
- The query function returns all tasks by a certain user. We use our by_user index to filter, and order by _creationTime (internal variable) descending.
- We create a new task by the user.
- We update the completed task by a user.
- We remove a task by a user.
🎇 All of these are secure, close to the database and extremely fast. The fact that we have to run multiple database calls is negligible in this case!
Creating Our App
Even though the convex folder is created on our server, it does not live there. The rest of the code actually lives in our app.
Composables
If you follow any of my articles, you know that I firmly believe your core code should ALWAYS be separate from the component, in a composable, not in the component.
- useConvexQuery is simple, has a pending and error state and can be passed directly to our app.
- useConvexMutation is more complicated. We want our apps to be immediate, so we must add the optimistic update strategy like Firebase has.
- There is a optimisticUpdate option that gives you access to localStore.getQuery and localStore.setQuery. We can set our items optimistically, and Convex will automatically roll it back if there is an issue.
app.vue
We show a loading spinner or a Sign In button.
AddTask.vue
Again, with our composable all we really need to do is show the input button and error.
TaskList.vue
We can easily show our task, handle removing them with a button and toggle completed state.
LoginWithGithub.vue
Of course we have to show our GitHub login.
And loading spinner.
⚠️ No Convex Composable
Convex is meant for React. They don’t have the ability to log in or log out natively outside of React!!! If you dislike React as much as I do, you have to string together working auth client functions from their React codebase. This works, but is just generated slop code. Hopefully they fix this for Nuxt and SvelteKit at the very least.
📝 These functions just handle signing in and out, loading and authenticated states.
👎 What bothers me the most about this is that this code doesn’t have to be React-specific. It just sets some storage states, etc. It doesn’t do anything special, as that is already handled in the core code. This is client-only, not even SSR. What’s worse is that this could easily have been built framework-agnostic anyway. Instead, we have another React-only database. ☹️ People hate JSX, it is a thing; they just deal with it.
Verdict
What Convex Says
Let’s start with Convex’s comparison:
However, I find this to be incomplete at best, and incorrect at worst. This is what the table should look like, only keeping those features
noSQL is NEVER relational, and you can emulate that with either database in different ways. They both have local development, which works differently.
Transactions and schemas are available in both. React support is definitely available in both, but Convex does NOT have first class support for Nuxt or SvelteKit, which I believe is a must these days, especially if you need authentication.
I would also argue that due to pipeline operators, Firebase can now handle relationships way better than Convex ever can.
Where Convex Wins
- TypeScript and React developers-first
- Just write trigger directly in TypeScript
- Better at handling security directly
- Better foreign key and creation time handling
Where Firebase Wins
- Very mature ecosystem for support and features
- Handles all frameworks
- Setup is seamless and very easy to use
- Has many querying capabilities and helpers for scaling
📝 Convex got some traction after Theo started using it for his t3.chat app. Theo is heavily into React and TypeScript, so this makes sense.
Final
Convex seems to prosper where Firebase is lacking. A lot of people don’t use Firebase Security Rules correctly, or at all, because they are hard to maintain. You get the same problem with Supabase RLS.
Convex is just TypeScript. The setup is terrible, but the developer experience after that was very intuitive once you understood it. I could see this really helping you build something that scales quickly.
Firebase still wins for me, but mainly due to maturity.
Here is what I would like to see in Convex for it to be a stronger contender for my needs:
- First-class support for SvelteKit, NextJS and Nuxt. Not everyone uses React.
- First-class support for authentication. The code that is written for React only can easily be modified to support all frameworks. The docs need to show setup once complete. This should also include server authentication with cookies etc.
- Convex is a noSQL database and its documentation shouldn’t confuse relations. It is not clear how you data model. It is also a plus for Convex how they explain how running multiple await for database calls can be done close to the database in a transaction to emulating a join… I just wish they didn’t confuse it for a join. It is OK that it is noSQL.
- A simplified .env management, as it gets confusing where it lies, especially when with production and development databases as well as local and production hosting.
- Examples for when you don’t need real time and you want to load on server only. This is just as important.
I think as Convex matures it could really be amazing, but it is not quite there if you want everything as plug-and-play as Firebase.
Repo: GitHubDemo: Vercel Functions
