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

[kripod]

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! 🙏

[balazsorban44]

So this has actually been asked several times before, and @iaincollins's reasoning is the following:

We deliberately use a REST call rather than bringing in all of NextAuth.js and the database Adapter into a Lambda (and I'm very keen to keep it that way).

I am not sure what his opinion was on making an alternative method that would allow the user to deliberately do what they want accepting the consequences. @iaincollins? What do you think?

Related: #1199, #947 (comment), #212 (comment), #212 (comment) and probably more.
Potentially related: #1478

[kripod]

@balazsorban44 thanks for your quick response!

Some deployment services (e.g. Vercel) bundle all the API routes into a single Lambda, so there should be no significant size difference between the fetch-based version and importing already bundled functions directly.

The isomorphic getSession method should be viable once React Server Components are released – so that fetch calls targeting local API routes can be called without network overhead. Until then, I think developers should have a choice between the isomorphic and a server-only variant of getSession, getProviders, etc. They should possible be called getServerSession and getServerProviders, respectively.

[iaincollins]

I think developers should have a choice between the isomorphic and a server-only variant of getSession, getProviders, etc. They should possible be called getServerSession and getServerProviders, respectively.

I think something like this is reasonable in principle but we'd need to address how passing app configuration is handled in a consistent way in different environments (i.e. consistant behaviour that allows for, but doesn't assume, shared context for all functions).

I've got ideas about how I'd like config to work the longer term, but I'm open to suggestions for interim solutions.

[rozenmd]

This issue is particularly noticeable when Vercel's platform experiences additional latency - API calls to a protected endpoint simply start timing out.

Anything we can do in userland to avoid the additional network request?

[kripod]

@rozenmd These issues may also related to the problem: #1832, #602

[janpio]

To add a data point here: prisma/prisma#7009 (comment) This is a Prisma user who attributed the latency in his app to Prisma in the beginning. We then, with the help of @kripod, figured out that this might indeed be a Vercel deployment + Nextauth issue as described above.

Fixing this in some way or protecting users in serverless environments would be very nice. (And yep, we know the pain of serverless deployments at Prisma as well. We are trying everything to make it nice for people, but some problems are just still unsolved. [which is totally not Vercel's fault by the way, they are doing an amazing job of making serverless usable in the first place - but now people use it 😆])

[balazsorban44]

You can see the original comment what I used to base my answers on protecting our current implementation: #947 (comment) but I'm getting more and more convinced that this has indeed been a poor choice, especially when the reason behind it was to better support serverless environments. It seems to me that it kind of has the opposite effect of what the original implementation wanted to achieve.

[rozenmd]

FYI I managed to roughly half the cold-boot impact by bypassing getSession when the session is valid: #1673 (comment)

[balazsorban44]

I created a temporary version at 3.22.0-canary.2

import {getServerSession} from "next-auth"
import {options} from "pages/api/auth/[...nextauth]"
export default Page(){
  return null
}
export async function getServerSideProps(context) {
  return {
    props: {
      session: await getServerSession(context, options),
    },
  }
}

And in your [...nextauth].js you have to extract the options into its own const, so you can share it in the page file. This configuration could ultimately be extracted into something like next-auth.config.js or similar I guess, but this is a Work In Progress for now.

Very interested if someone could check out if it helps. The getServerSession does not do fetch

[rozenmd]

Keen to check it out @balazsorban44 - is there a PR/branch I can look over?

[balazsorban44]

the code is only available locally currently it is just a quick and dirty implementation, so nothing to look at there. the more interesting part is if it makes any difference in performance. check out the above mentioned version