SSR on first page request, then CSR between pages.

[emadabdulrahim]

Libraries versions

"next": "^9.4.4"
"next-auth": "^2.0.0"

Hi,

Is there a way to get User Session on first page request as SSR, but subsequent requests to other pages would run CSR since I can store session in memory?

Right now I have to implement getServerSideProps on all logged-in pages. Which makes my entire app SSR and routing between pages become slower even though most pages don't do any data fetching in getServerSideProps

Here's a sample of what my getServerSideProps look like:

const { getSession } = require('next-auth/client')
/*
..
..
*/
export async function getServerSideProps(context) {
const session = await getSession(context)

  if (!session) {
    context.res.setHeader('location', '/')
    context.res.statusCode = 302
    context.res.end()
  }

  return {
    props: {
      session,
    },
  }
}

My CSR hack right now is to get the session inside _app, and check on the pageProps if it's isProtected. Which means the initial page request UX is a bit nasty because until I get session or undefined, I don't know what to show to the user. Also if there is no session, there'd be a heck up before I can redirect them to login.

Is this a current limitation of NextJS or is there a way to achieve my dream?

[emadabdulrahim]

Any guidance on the question above, please? :)

[ryanbahan]

Regarding CSR on other pages, can't you just use the NextAuth useSession hook inside the component body to get what you need client-side?

[emadabdulrahim]

Yeah, I can do that. But what would the UX on those page look like when I refresh the page? If they don't implement getServerSideProps then they will attempt to render, and if !session, will redirect the user.

And if they do implement getServerSideProps to get a better UX on initial app load (server decides to redirect user or not), then all my pages would be SSR.

Am I missing something or is this how it is?

[ryanbahan]

I guess I'm not seeing a clear issue with the first scenario you outline. On page refresh, the client will re-render page contents exactly the same. And, like you said, if the session expires it will redirect them. Since the client-side rendering is pulling from data you already have, the time it takes to render (I imagine) is fairly nominal, and thus the decision to redirect would also happen pretty quickly.

You can also mix these two things and use getServerSideProps to check for a session, and then render the data client-side. Maybe that's a nice middleground?

[emadabdulrahim]

I guess I'm asking for a feature that doesn't exist? Render first page request for the entire app SS, then subsequent requests are CSR.

[ryanbahan]

Ah, I see. Maybe you could do some sort of conditional check in getServerSideProps to accomplish this?

[emadabdulrahim]

Wouldn't that mean I'd put getServerSideProps on all pages that would have that conditional? If not, could you give a pseudo example?

[ryanbahan]

If you're trying to have an approach that's SSR first, then CSR (on the same page), then yeah you'd have to insert getServerSideProps on any page you want that to happen on.

[mattjennings]

I've also run into this same scenario. I'm not sure what the solution is, or what I want as a solution if there is none... I suppose it would be going back to getInitialProps?

In my case, I'm using SSG pages with client-side authorization so I don't have to SSR every request (which leads to slower pages as they can't be cached). I would rather redirect if it's an invalid session for the very first request before the page is served. I can use getInitialProps to do exactly that, but then I lose the ability to use SSG pages.

Maybe there could be a way to opt into some server side page handler that doesn't affect the content of the page, so they can still be SSG? Basically getInitialProps without the props part :P

[ryanbahan]

Maybe I'm missing something, but I don't see a reason you can't cache SSR pages. You just have to implement that functionality yourself and build a client-side data cache.

You won't be able to mix SSG with other options as you mentioned, but you could viably use SSR to do your auth/redirect, and then write up a small client-side cache to store the data. Then in your SSR you could check for the cache (via a cookie or similar) and if it exists, just use that cached data. That flow shouldn't eat up much page load time, and you won't have to deal with client-side redirects.

[mattjennings]

Ah, no, it was me that was missing something- you're right. I re-read the Vercel docs on caching and I see that unless I'm using the Authorization header then they should be caching.

That's an interesting suggestion though. That essentially would give me what I'm wanting in this "once per session" handler, so I think I will give that a go! Thanks for the input.

[ryanbahan]

No problem, good luck!

[emadabdulrahim]

@ryanbahan The problem I have is that SSR is page specific. Could you help me understand how to run code on the server that wouldn't make it page specific request?

Sorry I'm still having trouble wrapping my head around this.