Server-side HTTP requests via `getSession` usually get extremely slow on Vercel

Describe the bug

Before further ado, here’s a comparison between a /api/user/{id} request which fetches /api/auth/session through the network even on the server side, versus a /api/site/{id} call, which isn’t protected via getSession. Unfortunately, there’s a quite large margin between response times.

Steps to reproduce Call getSession on the server side and observe that it makes an HTTP request instead of just calling functions locally.

Expected behavior Calls to getSession should be executed locally in a server environment. A separate getServerSession method could be added as a non-isomorphic solution without any HTTP calls.

Additional context According to the official Next.js docs:

You should not use fetch() to call an API route in getServerSideProps. Instead, directly import the logic used inside your API route. You may need to slightly refactor your code for this approach.

Fetching from an external API is fine!

This seems to hurt performance badly.

Feedback Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

Thank you for maintaining this wonderful library – it really helps a lot! 🙏

[trentprynn]

TLDR

• This has resulted in a 100% (2X) speedup for basically every action in my application
• Here’s source code for my habit tracking app which is now exclusively using getServerSession and runs on vercel serverless api functions

Here’s my write up of changing to use getServerSession solely in my application

Just as an update to other who are interested in the getServerSession method in regards to implementation and possible performance gains when running serverless on Vercel

I use NextAuth heavily in my open source daily habit tracking application which uses Next (Full SSR Frontend + API) + NextAuth + Prisma + Postgres and is hosted on Vercel. This means all of my API functions are deployed as server less functions and I do all of my auth checking in server side rendering methods for my pages.

Previously NextAuth’s use of http fetch in the getSession method severely hurt performance when run on vercel’s serverless functions – imagine the following flow and the amount of HTTP requests that were happening on Vercel’s platform where HTTP request startup time is the largest hindrance for performance

1. User that’s already logged in navigates to habitapper.com (1)
   • http request (1)
2. SSR for page does fetch request for session (2) -> finds a valid session -> redirects user to habitapper.com/habits page
   • http request (2)
3. User loads habitapper.com/habits (3) -> SSR does fetch request for session (4) -> finds session -> uses internal method (non-http) to get habits for that user and passes them in props to component
   • http requests (3, 4)

With the new getServerSession this removes http requests (2) and (4) because the SSR method is directly accessing the logic to retrieve the session without having to make an http request.

Some notes about current implementation if you’re looking to do this in your application

1. I had to use next-auth@0.0.0-pr.3222.41318883, when I tried using the getServerSession method with next-auth@4.0.0-beta.7 every call failed to fetch the session and I got errors in console – these went away when I upgraded to this experimental version and I assume will be fixed in auth@4.0.0-beta.8 when it’s released
2. You’ll need to modify your pages/api/[...nextauth].ts file so you can access the NextAuthOptions object which you’ll need to export and use anywhere you want to use the getServerSession method
   • example in my code
3. Using getServerSession in a server side rendering function differs from using it in api route
   • example on API route
   • example on SSR page

[balazsorban44]

@walid-mokrani looks promising, would you care to open a PR against our next branch? I’m pretty sure we could tune it a bit and make it part of the v4 release!