4 ms·

Hi Colin! On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (cl

Hi Colin! On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally) We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend: https://backend-docs.clerk.dev/quick-starts/next.js-api-routes#3-create-an-api-route https://backend-docs.clerk.dev/quick-starts/next.js-api-rout... Soon we will launch a way to add custom attributes to the user object, as well as management of those attributes in the UI if desired. Things can get a bit murkier there, but those features will always only be opt-in.

colinmorelli 6y ago
Thanks for the reply! I think your last point is what worries me the most. I feel like it makes sense to tackle custom attributes, because you own the user management pages. But, I also feel like you're almost never going to be able to support the kind of flexibility customers will need if those fields are anything more than simply metadata. It's nothing about Clerk specifically, it's just a problem with these kinds of products. I just worry that as your customers grow and scale, they naturally need to leave your platform (or downgrade to an auth-only solution). I'll definitely be curious to see how the product grows, though!
- colinclerk 6y ago
  Completely agree with everything here. It's not documented yet, but our frontend components leverage an API that was built with the expectation that some developers won't like our designs, or will need something custom we can't accommodate. In those cases, using the API directly should offer the flexibility you need.