Server-side vs client-side authentication with Next-auth (caching)
Unanswered
Florian posted this in #help-forum
FlorianOP
I need some clarification here.
Let's say I want to display the currently logged-in user in the navbar.
If I fetch the session server-side (
Considering this, would it make sense to move the session retrieval client-side, if I want to enable static caching? This would be done by wrapping the layout into a
<html lang="en">
<body className={inter.className}>
// Not passing the session prop here will make the provider fetch it
client-side
<SessionProvider>
<Navbar />
{children}
</SessionProvider>
</body>
</html>
Am I missing something? Like another better option? Or any caveats about my approach?
Let's say I want to display the currently logged-in user in the navbar.
If I fetch the session server-side (
getServerSession or now just await auth() in v5), all pages that display this navbar are dynamically rendered. There is no way to statically cache them anymore, correct?Considering this, would it make sense to move the session retrieval client-side, if I want to enable static caching? This would be done by wrapping the layout into a
SessionProvider, not passing a session prop, and then retrieving the session via useSession inside the navbar.<html lang="en">
<body className={inter.className}>
// Not passing the session prop here will make the provider fetch it
client-side
<SessionProvider>
<Navbar />
{children}
</SessionProvider>
</body>
</html>
Am I missing something? Like another better option? Or any caveats about my approach?
7 Replies
@Florian I need some clarification here.
Let's say I want to display the currently logged-in user in the navbar.
If I fetch the session server-side (`getServerSession` or now just `await auth()` in v5), **all pages** that display this navbar are **dynamically rendered**. There is no way to **statically cache** them anymore, correct?
Considering this, would it make sense to move the session retrieval **client-side**, if I want to enable static caching? This would be done by wrapping the layout into a `SessionProvider`, **not** passing a `session` prop, and then retrieving the session via `useSession` inside the navbar.
<html lang="en">
<body className={inter.className}>
// Not passing the session prop here will make the provider fetch it
client-side
<SessionProvider>
<Navbar />
{children}
</SessionProvider>
</body>
</html>
Am I missing something? Like another better option? Or any caveats about my approach?
I would use client side rendering here, though I think partial prerendering can also be used to render a dynamic slot inside a static section
@joulev I would use client side rendering here, though I think partial prerendering can also be used to render a dynamic slot inside a static section
FlorianOP
By client-side rendering, do you mean fetching the session client-side?
Yes
FlorianOP
Thank you. And for PPR, I would wrap the user button into a
Suspense? This seems like an interesting solution too.@Florian Thank you. And for PPR, I would wrap the user button into a `Suspense`? This seems like an interesting solution too.
FlorianOP
Just tried it out and a Suspense boundary alone was not enough
I can’t comment on ppr since I haven’t used it myself and it still remains unstable
FlorianOP
Thank you. Client-side fetching does exactly what I need so I guess I'll go with that ðŸ‘ðŸ»