Read authenticated user in RSC

[dhmacs]

In the past weeks we've been starting to use the new Next.js app router and with that we're exploring how to use React Server Components.
One of the topics that we need to figure out is how to use authenticated user data in RSC. I know very little of how auth works in the PHP app and I'd like to learn more.

What would be the best approach to get the authenticated user server side? Should I just read the session cookie and implement the node.js equivalent of the PHP verification?

cc @sterlinghirsh @danielbeardsley

[sterlinghirsh]

I think the only way it can work is to make a request to the user api. There's no info encoded in the session cookie; it's just an ID to look up in our db. If the user api doesn't have what we need, we can look into adding it, but let's figure out what specific data we need. I'd be a little concerned with additional latency if we have to frequently refetch user info on the server though.

I think once we start taking the session into account, we'll have to be more careful about caching. The cart varies on the session, so I don't think there's much we can cache there. The avatar/user menu varies on the logged in user, but any logged out user sees the same thing. A handful of things vary on whether the logged in user is an admin or not. However, I believe the product page and product list main content only vary on the user's discount tier. We might be able to store a separate cookie with the discount tier and convert that to a path param in an edge middleware or something so that the correct prices can be cached for each class of user. If we allow the cart and avatar to come in client side, that might be a viable approach, though I'm not sure if that will defeat the purpose of trying to use RSC. I think the most important case to cache is the default price tier, which is all logged out users and the vast majority of logged in users. Anyway, I may be getting ahead of myself. Let me know if this answers your question.

[danielbeardsley]

In general, I'd prefer to generate the anonymous version of the page (so it can be cached) and then render the authenticated user bits client-side.

Rendering user-specific content on the server means the html response can't be cached at all, so we'd be effectively removing CDN caching entirely for pages where we sometimes render user-specific content server-side.

There will be pages containing enough user-specific content to make this strategy not viable, but I think those will mostly be entirely user-specific content.

[dhmacs]

I believe the product page and product list main content only vary on the user's discount tier.

That's exactly the problem that prompted this 👍

We might be able to store a separate cookie with the discount tier and convert that to a path param in an edge middleware or something so that the correct prices can be cached for each class of user

This might actually be the solution I'm looking for. We could make it a bit more generic just in case we want to store other user settings in the future and we won't need to worry about caching user data if what we need is already inside the cookie. 👍

If we allow the cart and avatar to come in client side

Yes these very likely are fine to have as client components, especially the avatar.

---

In general, I'd prefer to generate the anonymous version of the page (so it can be cached) and then render the authenticated user bits client-side.

@danielbeardsley I generally agree with this sentence, but there are places where we can do more than this and have the best of both worlds 👍
To give you more context, during yesterday meeting I've shared with @sterlinghirsh a demo of the product list page (only the search and filter section) built entirely with React Server Components (without react instantsearch, just querying algolia on the server — here a not polished preview).
If we had to render this client side based on the user then we would defeat the whole purpose of RSC because we would need to use client components.

What Sterling is proposing seems like a good solution for our problem. The page will still be cached if the cookie is not present (and as Sterling suggests we might be able to cache the discount tier version as well).