Hey Henrik!
That’s because these are things I need for some API requests and I want to avoid the extra round-trip to Stytch and application-side join to fetch those details.
Some features (such as showing collaborators on a document) require me to list a set of members with their name and profile image in an efficient way. These are part of the member info from Stytch.
Got it, that all makes sense!
Yes for some of the data, but for things like name & image I’d prefer to have those managed by stytch (since these details could e.g. come from OAuth / SCIM / …). Though I’m sensing that’s not the architecture that people usually go for?
I think most customers rely on Stytch Member objects (including Member trusted_metadata and untrusted_metadata) to store a lot/ most of their user data. That said, there are definitely use cases where additional user data needs to be stored in a separate DB. The right approach likely just depends on the specifics of your application, and in your case, it does sound like a hybrid approach (some data stored in Stytch Members, some stored in your DB) may be the way to go.
I guess I can do this by routing token exchange via my own backend endpoint, which then sets the
stytch_session_jwtorstytch_sessioncookies for the client-side SDK to pick up?
In this case, I think the most common solution is to populate your DB with the new user’s data upon calling our frontend discovery.intermediateSessions.exchange or discovery.organizations.create methods (essentially, whenever the user is actually added to an Organization and a new Member is created). In other words, you’d make a call to your backend as soon as you receive a successful response from either of those two methods, and your backend would then add the necessary data to your DB (if it doesn’t exist already). You generally should be able to keep the authentication calls on the frontend in this case.
Does that make sense in the context of your application?