I'd like to apologize for the scuffed audio. My Shure died while I recorded this the first time, so I had to re-record on my back up mic and couldn't find the Pop filter in time. This is 100% Rode's fault for breaking my mic.
I’m largely in agreement with the idea here but what if you need to change Auth provider. Without a users table you are placing a huge amount of trust in your auth provider. I’m addition there are huge amounts of compliance & law that requires users data to not be held with 3rd parties. To be clear, I’m not against this concept. But I do think it’s half a story
Sure in “some” scenarios you need the data to be stored due to laws although the restrictions is more about data location (EU looking at you) and other ones require auth data to be stored on location usually also have self hosting requirements. You should put a large amount of trust in your auth provider, if you don’t trust them with your auth and user data, don’t use them at all.
Brilliant! Great way to get locked into third parties. No good reason to outsource auth , other than wasting money on services which should be built in
Nothing stops you from later on exporting user data from the provider and implementing the auth layer yourself. Given that many auth services are free up to a certain point but your dev time isn't, this is a no-brainer.
I respectfully disagree. I’m fine with using clerk’s id. I’m fine with clerk handling passwords, auth keys, etc. heck, I don’t want to deal with all of the troubles associated with storing those. I’m not fine with clerk storing all of the user data I would need for my application to function. 1) There is an additional network call present. I don’t want more network related headaches. I don’t want another synchronous http call. I don’t trust the network. And yes, I know, that DB lookup is a network call, just without this one, there is nothing that can be really done. If you have own users table, worst thing that could happen when a partition between you and clerk occurs, is that your auth is broken. A risk I’m willing to take. Without users table, my application cannot do anything until the partition is resolved. 2) Point 1 can be mitigated with a cache. But at this point you are once again maintaining some form of a user table, that you need to keep in-sync with clerk. 3) Integrating data with a third party is a pain. All of the problems of distributed systems: data consistency, atomic updates, 2PC troubles, etc. strike you all at once. To be fair, even with users table you would have to integrate clerks data into your system. Just feels like there are less severe inconsistencies when the boundary is just a userID, and not the whole user’s state. 4) I don’t see how storing user data on the auth provider side helps me. Sure, storing credentials, keys, etc. is something I’d like to avoid. User data is radioactive; the less I know - the better I sleep. Yet, all of the user info, other than credentials, I do need to know to function. Not like I could outsource all of my application logic / rendering to the auth provider. And besides, not that issuing a "create table" db call is a big problem I’d like to outsource. You are managing a database anyways, storing a username amounts basically to no additional dev cost.
Side note: a bigger font on code, would help a lot with consuming this content on a mobile device. Tho, the whole “presentation” is enjoyable to watch, nothing that may irritate me much. ❤
yeah i had to re record the video, then my mic broke and the edit i shipped it when forgetting a zoom, it was a wild ride to ship. Usually yes all my stuff is zoomed
Might be worth linking to this vid in your blog post - I found that first and realised it was a video due to the screenshots, and then had to dig to find it.
In the example 5:08 is storing the username in posts table. If the user change the "username" in Clerk the developer will need to update all user's posts with the new username. It's not ideal Also in general I don't like the idea of giving the most valuable data on my app (the users) to a third party provider. The value clerk adds is awesome but for me doesn't worth it trading it for my users info. Just my opinion
Sure he could of used user_id instead and then issue one is removed. as i always say: - Roll your own auth - Use an auth provider You do what’s best for your company, clients or side project.
Seems there is a big push to use third-party providers for everything in the JavaScript ecosystem. From databases, caches and even cron. I don't know if it's lack of competencies or what but it doesn't make sense.
So in regards to this tenant table and clerk, how do I populate my tenant table with user info? Does clerk provide a webhook that tells my api when new users register and pass their info? Do I just lazy initialize (fetch from clerk and cache) it if I need user info and it doesn’t exist in my table?
Great video! is there any documentation on how to integrate clerk with a existing Users table? Let's say I already have a Users Table with Posts relations, and I want to integrate clerk without the users lose their posts.
Or you could circumvent the user table entirely, store it in Clerk metadata. Which a lot of users will do. Store secret data in private, data you need on the client (read only) in public metadata.
@@williambrandin1396 I’m not storing any user info, still pulling that from Clerk. But the users table I guess more mimics his Tenant table example and is just a bridge table (for lack of better words).
Love your content dude! On another subject i've been taught mongoDB in bootcamp but i'm slowly coming to the realization i'm going to need sql to build solid project backends. Would you be inclined to make a video about them both?
I'd like to apologize for the scuffed audio. My Shure died while I recorded this the first time, so I had to re-record on my back up mic and couldn't find the Pop filter in time. This is 100% Rode's fault for breaking my mic.
No worries. Btw, do you think the users table might make a comeback in 2024?
nope, i hope 2024 will see more adoption of this when using auth providers
I’m largely in agreement with the idea here but what if you need to change Auth provider. Without a users table you are placing a huge amount of trust in your auth provider.
I’m addition there are huge amounts of compliance & law that requires users data to not be held with 3rd parties.
To be clear, I’m not against this concept. But I do think it’s half a story
Sure in “some” scenarios you need the data to be stored due to laws although the restrictions is more about data location (EU looking at you) and other ones require auth data to be stored on location usually also have self hosting requirements.
You should put a large amount of trust in your auth provider, if you don’t trust them with your auth and user data, don’t use them at all.
Brilliant! Great way to get locked into third parties. No good reason to outsource auth , other than wasting money on services which should be built in
Nothing stops you from later on exporting user data from the provider and implementing the auth layer yourself. Given that many auth services are free up to a certain point but your dev time isn't, this is a no-brainer.
I respectfully disagree. I’m fine with using clerk’s id. I’m fine with clerk handling passwords, auth keys, etc. heck, I don’t want to deal with all of the troubles associated with storing those. I’m not fine with clerk storing all of the user data I would need for my application to function.
1) There is an additional network call present. I don’t want more network related headaches. I don’t want another synchronous http call. I don’t trust the network. And yes, I know, that DB lookup is a network call, just without this one, there is nothing that can be really done.
If you have own users table, worst thing that could happen when a partition between you and clerk occurs, is that your auth is broken. A risk I’m willing to take.
Without users table, my application cannot do anything until the partition is resolved.
2) Point 1 can be mitigated with a cache. But at this point you are once again maintaining some form of a user table, that you need to keep in-sync with clerk.
3) Integrating data with a third party is a pain. All of the problems of distributed systems: data consistency, atomic updates, 2PC troubles, etc. strike you all at once.
To be fair, even with users table you would have to integrate clerks data into your system. Just feels like there are less severe inconsistencies when the boundary is just a userID, and not the whole user’s state.
4) I don’t see how storing user data on the auth provider side helps me. Sure, storing credentials, keys, etc. is something I’d like to avoid. User data is radioactive; the less I know - the better I sleep. Yet, all of the user info, other than credentials, I do need to know to function. Not like I could outsource all of my application logic / rendering to the auth provider.
And besides, not that issuing a "create table" db call is a big problem I’d like to outsource. You are managing a database anyways, storing a username amounts basically to no additional dev cost.
Side note: a bigger font on code, would help a lot with consuming this content on a mobile device.
Tho, the whole “presentation” is enjoyable to watch, nothing that may irritate me much. ❤
I think point 1 it’s an extra network call is a lack of understanding of Clerk but that’s okay.
The rest and all is valid in some scenarios for sure.
yeah i had to re record the video, then my mic broke and the edit i shipped it when forgetting a zoom, it was a wild ride to ship.
Usually yes all my stuff is zoomed
Might be worth linking to this vid in your blog post - I found that first and realised it was a video due to the screenshots, and then had to dig to find it.
In the example 5:08 is storing the username in posts table. If the user change the "username" in Clerk the developer will need to update all user's posts with the new username. It's not ideal
Also in general I don't like the idea of giving the most valuable data on my app (the users) to a third party provider.
The value clerk adds is awesome but for me doesn't worth it trading it for my users info. Just my opinion
Sure he could of used user_id instead and then issue one is removed.
as i always say:
- Roll your own auth
- Use an auth provider
You do what’s best for your company, clients or side project.
as the wise words of some ytber "My Disappointment Is Immeasurable And My Day Is Ruined" no words can describe how i feel
Seems there is a big push to use third-party providers for everything in the JavaScript ecosystem. From databases, caches and even cron. I don't know if it's lack of competencies or what but it doesn't make sense.
shipping speed, and you could move off many of those later
So in regards to this tenant table and clerk, how do I populate my tenant table with user info? Does clerk provide a webhook that tells my api when new users register and pass their info? Do I just lazy initialize (fetch from clerk and cache) it if I need user info and it doesn’t exist in my table?
Yeah we have a user created webhook, just use that to create your tenants table or you can do it after sign up with a check
Great video! is there any documentation on how to integrate clerk with a existing Users table? Let's say I already have a Users Table with Posts relations, and I want to integrate clerk without the users lose their posts.
Great way to couple the code to the very specific third party code. Dont repeat it -in prod- at home
people are doing this in Production today. thousands of company’s, thousands of individuals.
repeat at home, production, staging. 😅
Do people ever tell you that you look like you could be Tucker Carlson's son?
brah…
@@james-perkins ☠️
Deleting the channel
@@james-perkins 😂
Tucker Clerk son :v
How would you approach adding additional User specific data? For example, in my app I have stripeUserId, preferred payment type, etc.
Not that I fully agree with the video, but you can make a StripeUser table that links the Clerk user id to the stripe info.
@@williambrandin1396 sure. But what’s the difference between doing that and just having an Users table?
Or you could circumvent the user table entirely, store it in Clerk metadata. Which a lot of users will do. Store secret data in private, data you need on the client (read only) in public metadata.
@@jjrise no user information in your database
@@williambrandin1396 I’m not storing any user info, still pulling that from Clerk. But the users table I guess more mimics his Tenant table example and is just a bridge table (for lack of better words).
The next step is to ditch your auth provider and move away from subject-based authentication, replacing it with a capability model 😎
but you still need to store user info somewhere and connect the user/subject to the capability/role?
no , the next step is to use 3rd party post service and delete your posts table
Just drop your DBs and store everything in a json file. in icloud
Love your content dude!
On another subject i've been taught mongoDB in bootcamp but i'm slowly coming to the realization i'm going to need sql to build solid project backends.
Would you be inclined to make a video about them both?
about Mongo, probably not about sql servers absolutely
What code editor you have opened this project ?
I think in the video it’s the new Github browser but i use zed.dev in most my videos
I dont want to be rude, but this video is unrelevant for ANYONE who doesn't use auth provider. Like 90% of people. What a clickbait
those numbers are about as made up as easter bunny
Is there a way to access the userlist as in this example where Theo does clerkClient.users.getUserList(). I can't seem to find a way to get this done
that is the correct method for example
const userlist = await clerkClient.users.getUserList({
orderBy: '-created_at',
limit: 10,
});