4 ms·

What's the story around extensibility? I feel like it starts to get murky when the boundaries of data ownership are unclear. What if I have some bespoke user-le

What's the story around extensibility? I feel like it starts to get murky when the boundaries of data ownership are unclear. What if I have some bespoke user-level data that doesn't make sense for your system to store, but is massively important to my business (this feels to be the case for most products I build). Can customers extend your UI components? Do they store that data with you? One of the nice parts about authentication only is that it's relatively well-defined and not a place where customers frequently have variable needs (outside of just data sources to auth against). Cool idea either way though, and I like seeing more innovation in the space.

colinclerk 6y ago
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.

colinclerk 6y ago

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.