-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read authenticated user in RSC #1979
Comments
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. |
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. |
That's exactly the problem that prompted this 👍
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. 👍
Yes these very likely are fine to have as client components, especially the avatar.
@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 👍 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). |
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
The text was updated successfully, but these errors were encountered: