Is there any benefit to putting the db connection in the context versus having it as an global var?

Can I do this?

export const challengesRouter = router({
  getChallengeById: privateProcedure
    .input(z.string().uuid())
    .query(async ({ input }) => {
      const challenge = await db.query.challengeTable.findFirst({
        where: (columns, { eq }) => eq(columns.sectionId, input),
        columns: {
          id: true,
          sectionId: true,
        },
      });
      return challenge;
    }),
});

export const challengesRouter = router({
  getChallengeById: privateProcedure
    .input(z.string().uuid())
    .query(async ({ input }) => {
      const challenge = await db.query.challengeTable.findFirst({
        where: (columns, { eq }) => eq(columns.sectionId, input),
        columns: {
          id: true,
          sectionId: true,
        },
      });
      return challenge;
    }),
});

or in this way i have a benefit?

export const challengesRouter = router({
  getChallengeById: privateProcedure
    .input(z.string().uuid())
    .query(async ({ input, ctx }) => {
      const challenge = await ctx.db.query.challengeTable.findFirst({
        where: (columns, { eq }) => eq(columns.sectionId, input),
        columns: {
          id: true,
          sectionId: true,
        },
      });
      return challenge;
    }),
});

export const challengesRouter = router({
  getChallengeById: privateProcedure
    .input(z.string().uuid())
    .query(async ({ input, ctx }) => {
      const challenge = await ctx.db.query.challengeTable.findFirst({
        where: (columns, { eq }) => eq(columns.sectionId, input),
        columns: {
          id: true,
          sectionId: true,
        },
      });
      return challenge;
    }),
});

Solution:

Can you do it? Yes. Should you? I don't think so. When you create variable outside the tRPC router, they're all declares immediately before the Requests Paths object. I'll give you an example: ```ts...

Jump to solution

2 Replies

Solution

Alky•10mo ago

Can you do it? Yes. Should you? I don't think so. When you create variable outside the tRPC router, they're all declares immediately before the Requests Paths object. I'll give you an example:

const OutSideScopePrisma = new PrismaClient()
const randomVariableOutsideScope = "Random variable outside scope"

export const adminRouter = createTRPCRouter({
  getDisplayProducts: adminProcedure.query(async ({ ctx }) => {

const OutSideScopePrisma = new PrismaClient()
const randomVariableOutsideScope = "Random variable outside scope"

export const adminRouter = createTRPCRouter({
  getDisplayProducts: adminProcedure.query(async ({ ctx }) => {

and then, when you go into the pages/api/[trpc] on the build folder:

4394: (e, r, t) => {
        t.a(e, async (e, s) => {
          try {
            t.d(r, { a: () => h })
            var a = t(9926),
              i = t(7847),
              n = t(1713),
              u = t(2855),
              o = t(4668),
              d = t(5231),
              c = t(3524),
              l = e([a, i, d])
            ;[a, i, d] = l.then ? (await l)() : l
            let m = new c.PrismaClient(),
              p = 'Random variable outside scope',
              h = (0, i.hA)({
                getDisplayProducts: i.qF.query(async ({ ctx: e }) => {

4394: (e, r, t) => {
        t.a(e, async (e, s) => {
          try {
            t.d(r, { a: () => h })
            var a = t(9926),
              i = t(7847),
              n = t(1713),
              u = t(2855),
              o = t(4668),
              d = t(5231),
              c = t(3524),
              l = e([a, i, d])
            ;[a, i, d] = l.then ? (await l)() : l
            let m = new c.PrismaClient(),
              p = 'Random variable outside scope',
              h = (0, i.hA)({
                getDisplayProducts: i.qF.query(async ({ ctx: e }) => {

all the variables are declared right before the object in which your endpoints are declared. That is, these variable will be initiated for every single endpoint of the given router. That's not good. It would be problematic if there's a chance of them failing to initialize, so every endpoint would fail because of it. But that's not exclusive to here. The context also lives within this file. If you go check, it will be after all routers, at the end. So, if you have Prisma within the context, and also another instance of Prisma in a another variable outside the endpoint scope, for every request at an endpoint of the given router, you will be initializing 2 instances of Prisma. One by declaring at the top of the file, the other one for every endpoint that uses the context. Maybe you can do this if it's something exclusive to this particular router, since it's going to live within the router scope. Otherwise, it's not good. But i would also say that it's not terrible, since that's probably going to be on serverless land, you'll only pay the price of initializing useless variables. Anyway, take this with a grain of salt, i'm not a master of tRPC internals or anything. Hope this helps!

kbemaster•10mo ago

so it is a good idea only have the db conn inside the context thank you for the explanation you were very clear

Gaming

Programming

Is there any benefit to putting the db connection in the context versus having it as an global var?