Making session lookup faster

[joeynimu]

Hey,

I am new to next-auth, and I am setting this up on a project, and I have realized that the app is stuck on the loading state for some time. It seems like the session looks up isn't that fast, at least on my app/setup. I have attached a screenshot of a lighthouse audit; the app stays in the loading state for a few seconds, making my score go down.

Below is my setup;

// _app.tsx

import { Provider } from 'next-auth/client'
import ProtectedRoute from "components/protected-route"

export default function App ({ Component, pageProps }) {
  return (
    <Provider session={pageProps.session}> // <- uses default options
        <ProtectedRoute>
          <Component {...pageProps} />
        </ProtectedRoute>
    </Provider>
  )
}

 // protected route

 import { useSession } from "next-auth/client"
 import Spinner from "components/layout/spinner"
 import { useRouter } from "next/router";

 const ProtectedRoute = ({ children }) => {
  const [session, loading] = useSession();
  const router = useRouter();
  const { pathname } = router;
  const isAuthPage = pathname.startsWith("/auth/");

 if (loading) return <Spinner />
 if (!loading && !session && !isAuthPage) {
   router.push("/auth/login");
   return <Spinner  />
 }
if (isAuthPage) {
    return <div>{children}</div>;
  }

 return <main>{children}</main>
}

Also, is there a convention for passing the accessToken in any API calls header in a performant way without calling getSession for each request?

[balazsorban44]

So first, you probably don't want to block the rendering of pages for every route while waiting for the loading boolean to become true. I would rearrange your auth logic so it only applices for pages that need authentication.

You can have a look at my approach here: #1210 (comment)

That would probably make pages "faster" in a sense that non-authenticated pages would render immediatelly, rather than having to wait for auth state to change.

As for pages needing auth. The session lookup is as fast as your network config, and if you don't use a database, looking up user data should be relatively fast already, as it only parses a cookie on the backend and sets the content back. If you use a database, please check if not the database calls are the bottleneck.

I can also see you are using Provider to wrap your app which is nice, as subsequent useSession() calls won't actually make a new network request, just use the one cached in the provider. How often you want to fetch a new session value by visiting the backend can be configured:

On a last comment, pageProps.session is not something that comes magically, you have to send it from somewhere. In this case getInitialProps or getServerSideProps. So in case your pages use any of these at all, there is no real value in providing pageProps.session to Provider. Check out #1132 (comment) for a better explanation

[joeynimu]

@balazsorban44 Thank you for your insights and useful links.

I want to point out that my app is a "private" app because it requires the user to be logged in to all the pages. And if they are not, they are redirected to the login page. While your comments make total sense, I struggle to find a central entry point to check for the session.

If there's one show that page, else I redirect the login page. __app.js is a candidate for this, but I can't add the session via getServerSideProps or getStaticProps, for I will opt-out optimization features that nextjs offers.
I could do this in the pages, but I'd have to do this for all of them apart from the log-in one, and it might be unnecessary to do this on every route change. There has to be a better way that's not so repetitive and inefficient. I could also achieve this in the ProtectedRoute HOC; however, I can't inject the session via getServerSideProps or getStaticProps in a non-page component. I am still researching and trying on how to go about this, but if you have some pattern that might be helpful, please do share.