is it possible to share or access the TypeORM connection through the api routes?

[vgrafe]

Question
I'd like to access the TypeORM connexion. Is it possible without having to install TypeORM as a dependency and configure/create/access the connection on every api route?

What I am trying to do
I am trying to extend the User schema with a custom field, and update it within an api route defined outside of [...nextauth].js.

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

[vgrafe]

I found a solution, but am not convinced it is the right way to do this: I export the adapter created in [...nextauth].js, so it can be imported in other api routes. Then I can import and use as illustrated below:

// inside the api route `/api/something.js`...
import { adapter } from "../api/auth/[...nextauth]";

export default async (req, res) => {
  const cnx = await adapter.getAdapter();
  const someUser = await cnx.getUser(1);
  res.send(someUser);
};

Is that close to the intended use?

[iaincollins]

Hi there! This has come up a couple of times - it might be worth us having an FAQ entry about it.

Connections between Serverless endpoints are typically not shared, each endpoint runs in isolation, so you can't actually share them between routes as you would with something like a monolithic app using Express.

Connections on the same API endpoint are reused between requests though - so usually 1 open connection per API endpoint, unless you have a lot of traffic on an endpoint (in which case additional instances might be spun up).

Technically it is still possible to use Next.js as a monolithic app (e.g. in a Docker container) so there might be some people who would find this useful, but it's not our primary focus (as NextAuth.js, like Next.js, is primarily focused on Serverless).

Defining a model in one place (e.g. models/user.js) and importing that model in both [...nextauth].js and in a custom API route works great and is a good way to go. We could really do with an expanded example of how to do that.

[archywillhe]

hmmm I'm using a custom ORM and created 2 adaptors at 2 places like this:

const adapter = ():any=>{
  return Adapters.TypeORM.Adapter(
     process.env.NEXT_ACCOUNT_DATABASE_URL,
     {
       models: Models,
     }
    )
}

Working great locally.

But I keep getting No metadata for "User" was found in a serverless enviroment

[vgrafe]

I had this error when getting/creating a new adapter too often. In my case, I was running logic on a DB user field on every session callback. Removing this logic bit fixes the situation. A bit vague (I never identified the root cause), but I hope this helps.

[archywillhe]

@vgrafe Thanks for the pointer! Interesting. So it's about getting/creating a new adapter too often? And the error you see also only appears in a serverless environment as well? I was thinking maybe it has to do with optimisation Vercel is doing for the functionless calls.

In my case I was doing a direct Restful calls to perform CRUD operations. Further introspection suggests that it is related to #710. So I've just opened a ticket with more elaboration to see if anyone is getting the exact same error: #780

Also opened a discussion on Vercel about possible optimisation that may have accidentally messed things up: vercel/vercel#5299

[cryptiklemur]

You're also able to use the TypeORM methods:

import {NextApiRequest, NextApiResponse} from 'next';
import User from '@models/User';
import {getManager, getRepository} from 'typeorm/index';

export default async function GetAllUsers(_: NextApiRequest, res: NextApiResponse) {
    try {
        const user = getManager('nextauth').connection.options.entities.find((x: any) => x.options.name === 'User')
        const users: User[] = await getRepository(user, 'nextauth').find();

        res.json(users)
    } catch (e) {
        res.status(500).json(e);
    }
}

I suspect there's an easier way to grab the base entity type, to prevent needing to go through the manager