Is there anything that I should know about using Kinde auth in Convex backend app?
I know Clerk and Convex is valid but I can't find anything about Kinde and Convex on internet
55 Replies
I am stranger to approach variants. I have no idea. I studied Convex docs, I am confident I can build a system with Convex but first of all, I should handle the auth to do backend work with users
This user seemed to get it working: https://discord.com/channels/1019350475847499849/1172125658823020564
GitHub
GitHub - umuthopeyildirim/react-kinde-convex: Starter kit for React...
Starter kit for React with Kinde&Convex. Contribute to umuthopeyildirim/react-kinde-convex development by creating an account on GitHub.
Yes, that's the only result I found on Google
Well, if Kinde is not really commonly working together, isn't it kind of risky to choose it? Maybe future problems? Can't choosing Clerk or other auth from the beginning be better choice in this case?
More users have used Clerk at this point, so it's a safer choice if you don't have a strong preference.
I've chosen Kinde because it's significantly different costs, Clerk been putting too much on cost with its extensions/plugins
It does look like it's pretty easy to configure with their npm package though: they made a
ConvexProviderWithKinde componentGitHub
react-kinde-convex/src/main.jsx at main · umuthopeyildirim/react-ki...
Starter kit for React with Kinde&Convex. Contribute to umuthopeyildirim/react-kinde-convex development by creating an account on GitHub.
GitHub
GitHub - umuthopeyildirim/convex-kinde-auth: Convex database adapte...
Convex database adapter for Kinde Auth. Contribute to umuthopeyildirim/convex-kinde-auth development by creating an account on GitHub.
Is it a good idea to create a production Next web-app with that?
I am not really experienced to consider that myself, and I don't know how reliable their code is
I'm essentially trying to create a Inventory management system for restaurants to practice a safe approach.
My another concern was if I should create user model, also users restaurant model in the database schema, how auth systems communicate. It's hard to imagine the structure with Convex and Kinde, I don't know how they communicate, how it would work
I think that's auth provider's thing to know, I wasn't going to mention about that here but I did because we've been discussing about it since yesterday in Kinde's Support channel
I don't know how Kinde Auth works (never used it) but it's generally recommended to store your user data in Convex, otherwise you have to fetch the user data everytime through an action
Would I be much more comfortable if I choose Clerk instead of Kinde? Do you have any idea?
I think they told otherwise. They have custom properties for extra props in a user model and that would be enough so I wasn't going to create a user model in DB schema
I chose Clerk, because I'm running a hobby project so it costs nothing anyways
Your choice would be different in a production-ready app?
I mean my app will get production ready but I will never have much users etc. etc.
Here is the information I got in another post: https://discord.com/channels/1019350475847499849/1224663426538672128/1224809579981049977
Thank you a lot, let me check it
Wow, so I'll indeed create a user model in the Convex DB schema and I'll keep it completely sync with Clerk's. I am convinced to use Clerk, I just want to be safe and do whatever I want easily, doing something with users, users some stuff
Is there anything I should hestitate to do that? I mean, keeping it sync with Clerk, etc. are these valid practices? Would it work well for a production-ready app?
Sorry for my trash english, I'm just typing it quick
np, bro
yeah, i think so. It's just faster. You don't have to store everything in Convex. Some stuff you can call via the Clerk Client. I recommend to store everything you need on the server (eg. clerkId) and the rest of the information you fetch via the clerk client
at least I did it like that
My personl preference is to keep as little in Clerk as possible, so all convex query/mutations have access to the user data. However, if you want to use all the Clerk pre-built UI to manage user info, you need to keep them in sync
Yeah, the thing is Convex accessing the Clerk data easily I guess
yeah, in my case I built my own UI anyways so I had to create everything from scratch. But for me it wasn't really hard to keep everything in sync
Wouldn't mistakes happen in that way? I mean it sounds weird to coding a Clerk's database copier as we call Clerk's Convex side data. E.g. backend acting toward wrong user, not found user, sync errors
As I said I can't really imagine yet, I apologize
hmm, yeah, idk, maybe I rethink that.
I will test the two approaches out and will share my results
Can you elaborate it if you don't mind?
Also let's say, to keep it little in Clerk, so we avoid custom properties(e.g. "reputationStars: 5") and store that extra properties in Convex(How we do that?). Won't clerk have any idea about that
reputationStars and in Convex backend functions, I'll connect it to what?
Thank you so much for your help!
I am just looking for a safe, production-ready suitable approachIn a convex query, everything is cached and deterministic, so you can't call an http fetch from there. So if you want user data, it needs to be in the database
How we get it into our Convex DB?
You insert it when the user signs up, and if you really don't want to have your own user mgmt UI and want to use Clerk's, then you set up sync from Clerk -> Convex
So, Clerk will give the data instantly to Convex DB, and in any action toward user, Convex will send the data/action result to Clerk so both will update their knowledge instantly?
E.g. Clerk registered a user, Clerk sends the data to Convex and we use the data as our user model in schema
You can set up Clerk webhooks to update Convex but I'm not sure how immediate it is. From Convex, you could schedule an action to update Clerk when you change the user.
I agree it's a bit strange to be storing your users in two places. Having to fetch data from Clerk about your users and from your application database for everything else seems like a recipe for inconsistency.
If that's a strange method, what's the common practice then?
I will look for it, isn't not being immediate a problem? e.g. user lands on their dashboard but it says you are not registered
Although middleware is working by Clerk, so the protection should be Clerk's side but was just an example
I'd generally say:
1. Day 1, use Clerk's user management features, and only sync from Clerk -> Convex (you don't have a custom UI for users to change their own data).
2. Eventually build your own user settings page. Let them edit the data in Convex. At that point, you only copy info from Clerk -> Convex on sign-up and from then on, you are just in Convex and no syncing needed.
Clerk's built in UI wouldn't be a thing that I care about. I can build mine. Without considering the Clerk's user management UI, would it work seamlessly?
I wasn't aware what you meant by the user management UI I thought it was in code like Provider, Client
@ian Idk if this is the right spot to ask but how far is the Convex Auth Library and what will it exactly do?
Michal and I are working on it currently, and the design is still in flux. Some goals I'd love your take on: If you could only pick one of these, which would it be? No guarantees / commitments, just curious:
1. Make it easy to start using auth without signing up for another service. e.g. Convex-specific auth
2. Make it easier to use open-source libraries like NextAuth
3. Better integration with Clerk (e.g. it's easy to set up user storing & syncing)
I guess you didn't directly ask me but 3rd option would work better for me as you can guess in my case
I'm interested in everyone's take on this 🙏
The 3rd option is the one I would mostly consider.
The first option needs a lot of work (auth isn't trivial and is the most sensitive data to be touched) and since it isn't Convex goal to provide an auth service Clerk will always be better at it as this is their only goal.
Open-source libraries like Next-Auth will always need more work than solutions like Clerk and therefore I will always prefer something like it although it is nice to use open-source stuff.
And although I completely disagree with the people saying it but if I am fully in Convex (Convex Auth with no Clerk) many people will complain about vendor lock-in.
It would be super super nice to have a Convex Auth solution but idk if that is what Convex as a company wants.
So if it's fully working I think Convex Auth would be better than the having two services but yeah.
great feedback, thanks
You mentioned Clerk + Convex would work great if I could set up a system that keeps Clerk database and Convex in sync, also if I keep as little as like username, userId in Clerk and the rest Convex. So I guess that means everything else than authentication could be done with Convex.
Well, Clerk has many add-ons like these. Would they be built from us as well? Or is that something we should use from Clerk? I assume OTP must be done by Clerk I don't know though.
E.g. we just authenticate the user with Clerk and then code roles in Convex?
I am so sorry to bothering you with it but I am just asking because I don't know and can't find something online
I will check Clerk's TOS, if they are against that approach. It's okay to pay for extensions, I am asking because I'm told to keep as little as possible in Clerk side
Those features all sound nice, and a good use of Clerk IMO. The one that stands out to me as better in Convex state is "Enhanced roles" - I bet you'll want your "who has access to what and which organization are they in" to be in your Convex DB, not Clerk metadata. Make sense?
For sync, check out https://www.convex.dev/templates/clerk esp. https://github.com/thomasballinger/convex-clerk-users-table/blob/main/convex/http.ts
Templates
The backend application platform with everything you need to build your product.
GitHub
convex-clerk-users-table/convex/http.ts at main · thomasballinger/c...
Contribute to thomasballinger/convex-clerk-users-table development by creating an account on GitHub.
Great, thank you so much! I guess, last questions:
- I appreciate the tip you giving as I would want to roles to be in Convex side rather than Clerk. Is it a good idea to have every of these features in Convex? Is it possible? E.g. Device tracking and revocation, simultaneous sessions, user managing.
- Is there any impact on user experience due to this Convex and sync approach? For instance, would users need to wait longer for Convex to validate or querying the all users be slow if that's how it works? Would it affect the speed of the app? So is there any possible hestitation that I should be aware of?
I'm checking the template/repo. I appreciate your help!
You would be building all of the device tracking, revocation, etc yourself. Convex doesn't have any out-of-the-box features for these things, so if you want them soon I'd start with Clerk, and if you later want to build a more custom version of them you can build them from scratch later (or maybe find some library / component that works with Convex)
re: performance, your user queries will be alongside your other Convex data, so it'll be faster in that regard. However, there is a bit of a waterfall of requests:
- Clerk says you're signed in and the client gets the token
- Convex sends the token up, then calls something like
storeUser and a user is created / verified that it exists
- Your functions that depend on auth run
If you use SSR, you can do all of these quickly on the server and return authenticated results. If you do it from a client-rendered SPA, it takes a roundtrip longer to load when you first load the page. This hasn't been an issue in my experience, but if you wanted to work around it for now, you could optimistically call your queries before you validate a user is there, and have all of your endpoints return null if the user isn't there yet.
But generally if you're optimizing page load, you'll consider something like SSR which doesn't have the waterfall issue if you do use usePreloadedQuery - but I'd wait to optimize those until later.btw I wrote a post on moving quickly: https://stack.convex.dev/yolo-fast-mvp
YOLO: Get to an MVP fast
Before you burden yourself with “best practices” for large-scale companies, focus on what will reduce your feedback cycles and help you ship early and...
Your tips have been invaluable, and I am grateful for every piece of advice. They have not only answered my immediate questions but have also opened up new paths for consideration.
and it’s motivating to know that I can build upon its capabilities. I’m an excited learner, always willing to absorb new information that is suitable for my project and apply it, who wouldn't make their app better anyways.
I’m not looking for ready-made solutions; just knowing that I can build on Convex’s capabilities is enough, there must be a way and I'll try it till it works.
I'm determined to find the best approach for my application. You mentioned SSR might be better, as it prevents authentication from affecting fetch speed(our approach), but I'm really fixated on achieving a smooth user experience.
I was initially considering CSR and SSR, but I hadn't given much thought to SPAs until now. I've just realized that many popular apps, such as Slack, use SPAs. I used to associate SPAs with poorer quality or amateurish apps, like quiz app projects. So, I've only recently learned about them, and while I can't say much yet, the idea of client-side rendering is appealing to me.
With our current tech stack (Next.js 14 frontend and Convex backend, TS), SSR seems to have significant advantages, but I might opt for SPA for the sake of better UX or a hybrid approach depending on the situation.
You mentioned SSR would be better to avoid the waterfall issue, but from what I understand, the waterfall effect might not be a big deal, so it might be outweighed.
Since I'm not very experienced, I've been looking for any information that could help me on my project and I greatly appreciate all the tips you've given me. Anyways, I hope I did not bother you with my trivial questions, but once again thank you very much!
I also read your post, took my notes 🙂
Glad to hear it! I think learning to do things yourself is very valuable. I would say there are different paths depending on your goals:
- if your goal is primarily to learn, then it's fun to follow your curiosity about performance, ideal architecture, and comparing advanced capabilities of Clerk.
- if your goal is to ship a successful product, I'd focus on what is in the way of shipping something, and focusing on performance, SSR/CSR/etc. once you feel that is the biggest pain point of your app. I find using SSR too early can slow down development, since you keep having to fix hydration issues, think about where code is running, etc.
- SPAs are in hobby projects (because they're simpler to reason about) but they still are useful for large production apps. At Dropbox we didn't add SSR until years after making 100M+ in revenue, and in some cases it degraded TTI.
Thank you for clarifying the SPA aspect, and I'll ensure taking care of SSR at early stages.
I'm particularly impressed by the information about Dropbox; it's awesome to learn such valuable information. I used to love hearing interesting facts like that from my teachers too, haha.
Since my main motivation is shipping a product, this project is a learning experience to find the best approaches, but ultimately I learn to ship a product.
That was a great support experience for me, appreciate it again and I will reach you out again if I need support about Convex if you don't hestitate, so I don't want to keep you busy, this thread can be closed.
You're welcome! If you want to pay it forward, consider spreading the word about Convex 🙏 - a lot of developers don't yet know about us
Absolutely. I will mention about Convex. I'm kind of a Convex fan already 🙏
Our current plan is to use clerk and slowly add on our own components until we can be in full control of everything , then maybe by next spring be able to offer our various customers the ability to select from one of many auth providers. Clerk setup already seems to be easy compared to other options. But first we want to get to a deployable state where we can deploy convex + clerk in one click or something very easy. No web-hook back and forth etc. I haven't researched how doable this is right now.
Clerk has DB Sync in the roadmap. But idk if they will support Convex.
I hope they do, i found covex via clerk.
Yeah, I'm not sure about that. I think they will first support bigger DBs like the SQL ones. But if they built an easy-to-adopt adapter for databases that would be huge.
we'll chat with our friends at clerk. we know them very well, and the two teams are always looking for ways to work closer together
Hi, I have questions about the related discussion. https://discord.com/channels/1019350475847499849/1260611687820820566
Feel free to share your insights