The powerful alternative to Supabase and Firebase. Combine the speed of Convex (reactive backend) with Clerk (best-in-class authentication).
This plugin handles the heavy lifting token syncing, smart pagination, and websocket connections so you can build reactive, scalable Bubble apps with a modern, serverless architecture. Stop wrestling with slow APIs and complex SQL; get instant data sync out of the box.
Key Features:
-
Reactive by Default: Data updates instantly on your UI without page reloads.
-
Zero-Config Auth: Seamlessly syncs Clerk sessions with Convex database policies.
-
Bubble-Native Data Types: automatically converts Convex responses into Bubble data types.
-
Production-Grade Pagination: built-in Next / Previous cursor support.
-
Global Logic: Centralized path management (Sign in/Dashboard) for a cleaner, maintainable app.
Instructions
1. Clerk Setup
-
JWT Template: Create a template named convex with Audience set to convex.
-
Redirects: Add your Bubble domain to Allowed Redirect URIs in Clerk API Keys.
-
Paths: Set “Fallback development host” in Clerk Settings to your full version-test URL.
2. Plugin Configuration (Shared Keys)
-
CONVEX_URL: Your deployment URL.
-
CLERK_PK: Your Clerk Publishable Key.
-
CLERK_SIGNIN_PATH / CLERK_AFTER_AUTH_PATH: Define your page slugs (e.g., login, dashboard) here once. The plugin will handle the routing for all elements.
3. Usage
-
Place the Clerk Connector on your page to initialize the stack.
-
Use Convex Connector to Watch Query (Read) or Run Mutation (Write).
-
Add Clerk UI elements (Sign In, Sign-up, User Button) anywhere; they automatically respect your global path settings.
Demo: Signup
App editor: test-convex234123 | Bubble Editor
Status: Bubble team is reviewing it.
1 Like
At this point why even use Bubble?
I imagine the visual editor is helpful. If somebody were to use this approach of convex and clerk, what’s your suggested alternative to Bubble? Not code though, as it’s not an alternative to bubble.
I saw @georgecollier saying similar things on the OP other post, but was short on reasons for the quip and suggested nocode alternatives to bubble that would make better sense if a user were to leverage convex and clerk.
For me, I can say there’s probably lots of reasons to still choose bubble as front end because it’s not just a platform for database and front end, it does other stuff to keep a web app running? Or are there viable nocode visual editor alternatives that blow bubble out the water?
Yeah, but I don’t think it’s nice to shill a product’s competitors on their own forums.
1 Like
Or throw shade on a community members product showcase post?
1 Like
I mean, it just doesn’t really make sense.
Why would you externalise the GOOD parts of Bubble (realtime, backend, database, auth) and keep the worst part (frontend)?
Sooooo many people thing the obvious migration step is moving the backend out of Bubble and keeping the front-end but in actuality that just leads to the worst of both worlds because you now have a crap front-end and no benefit of using Bubble (all of your logic is gated through the subpar API Connector)
3 Likes
@boston85719
Bubble still makes a lot of sense as a frontend.
It’s fast to build real, production-grade UI (not just prototypes) and it’s far more controlled than vibe coding: fewer bad practices, fewer random issues, and fewer security problems caused by implementation mistakes.
Are there alternatives? Sure:
-
Code
-
Vibe coding
-
Nordcraft
But honestly: if you already know Bubble, it’s still the best visual option for building UI today.
The real problem isn’t Bubble’s frontend. it’s that Bubble alone doesn’t scale well as a backend and gets expensive quickly. Paired with a scalable backend, Bubble’s value is still very strong.
@georgecollier Here I disagree.
The worst part of Bubble is the backend, not the frontend:
-
You can’t execute real code
-
Everything is modeled as frontend-style workflows
-
Complex logic becomes fragile and hard to maintain
-
WebSockets / realtime frequently stop working
-
Scaling backend logic in Bubble is expensive and limiting
On top of that, Workflow Units explode because you’re forced to use Bubble’s servers, with inflated pricing.
Once you move the backend out:
-
You avoid unnecessary WUs
-
You avoid the API Connector as a bottleneck
-
You regain real control over cost and performance
The best part of Bubble is the frontend:
-
Extremely fast UI construction
-
States, flows, and responsive behavior without writing code
-
Ideal for rapid iteration and shipping
Moving the backend out doesn’t create “the worst of both worlds.”
It creates a more honest setup: Bubble where it shines (UI) and a modern backend where Bubble clearly doesn’t scale.
I mean, you can’t argue with that.
Bubble as a frontend is fine for specific types of applications. It’s fast, predictable, and if you know it well you can ship real UI without much friction.
But once you’ve already decided to split frontend and backend the equation changes.
At that point you’re not choosing “Bubble vs code / another platform” You’re choosing which frontend makes sense for a decoupled setup. And Bubble isn’t an obvious win there.
A few reasons:
• When your backend lives elsewhere everything turns into API calls through the connector. That gets awkward fast.
• You still keep Bubble’s limits around debugging, reuse, and more complex UI patterns.
If you’re already on something like Clerk + Convex, a frontend that’s built for that world (React, etc.) usually fits better. That’s not vibe coding. It’s just using the right tools designed for a split stack.
Also, “I already know Bubble” is real, but not enough of a reason to make long impacting architecture decisions.
@code-escapee
That assumption only holds if you route everything through Bubble’s API Connector, which isn’t required here.
In this setup:
-
Calls are made client-side, directly to Convex
-
They don’t go through Bubble’s server
-
They don’t consume Workflow Units
Security:
-
Clerk handles auth and JWTs
-
The client sends the JWT with each request
-
Convex validates the JWT server-side on every query/mutation
-
Read/write permissions are enforced in backend code, not in Bubble
Using the API Connector here would:
Convex validates identity and permissions server-side on every query and mutation using Clerk as the source of truth.
Bubble stays focused on what it does best: fast UI and visual flows.
Auth and authorization live where they should: in the backend.
???
Where do you think auth and authorization lives in Bubble?
1 Like
