tRPC v10 middleware implementation

[thisduck]

In tRPC 9, we get the ability to apply middleware to every query/mutation in a router as a result of chaining queries/mutations. However it seems like in v10 we'd have to individually apply certain middleware to each query/mutation individually.

Let's say I wanted to add a logger to all the queries/mutations, it would be nice to be able to apply the middleware to the main router instead of having to import it into all the individual routers.

So in the example below (modified from the alpha middleware example), it would be nice to place middleware on to the main router so that it applies to any routes and merged routes, etc.

import { initTRPC } from '@trpc/server';

export const t = initTRPC<{ ctx: Context }>()();

const logger = t.middleware(async ({ path, type, next }) => {
  const start = Date.now();
  const result = await next();
  const durationMs = Date.now() - start;
  result.ok
    ? logMock('OK request timing:', { path, type, durationMs })
    : logMock('Non-OK request timing', { path, type, durationMs });

  return result;
});



export const appRouter = t.router({
  foo: t.procedure.query(() => 'bar'),
  abc: t.procedure.query(() => 'def'),
  user: userRouter,
  post: postRouter, 
}).use(logger);

[thisduck]

Hmmm, I see. So the idea would be to define some kind of baseProcedure that would have the logger middleware applied. And then import baseProcedure everywhere.

I think that would suffice, please ignore. =)

[KATT]

Glad you figured it out :)

[huzaifahj]

So if we have 100 procedures split across different files and merged onto the main router, we should import and use the middleware'd procedure and use it in all those instances?

I can't see how this is sustainable.

Sure, it's nice to have granular procedure-level middleware. Again, that's not the general point of middleware and having it on a router-level is essential for any Node server framework.

[KATT]

You can define an adminProcedure and just use that locally in the admin router. Call it something short and it's the same thing as using t.procedure

[KATT]

This is how your admin router would likely look like:

import { adminProcedure, t } from '~/server/trpc';

export const adminRouter = t.router({
  secret: adminProcedure.query(() => 'a key'),
  secret2: adminProcedure.query(() => 'a key'),
});

It wouldn't be too much different to an API that you want which would be something like:

import { isAdmin, t } from '~/server/trpc';

export const adminRouter = t.router
  .use(isAdmin)
  .procedures(procedure => ({
    secret: procedure.query(() => 'a key'),
    secret2: procedure.query(() => 'a key'),
  });

... it's way more modular to have the authz checks etc straight on the procedure rather than on the router as you can have exceptions & it generally plays nicer together with adding sub-routers etc

[huzaifahj]

Thank you, understood

[rhyek]

@KATT completely missed the point here. if you have an admin namespaced subrouter, it makes complete sense to have the ability to apply some security middleware to all procedures within it to avoid the margin of error where a developer could forget to use the correct procedure type. think 10s or 100s of procedures within a protected router with common security checks.

[huzaifahj]

@rhyek I agree with you. Many users of tRPC within this discussion have raised ergonomics and security concerns which are being ignored by a framework that prides itself on at least one of those.

[nosuke23]

In the case of chaining middleware, we want to define each middleware separately without .use() like .middleware(). I think procedures should have middleware() function.

const isAuthed = trpc.middleware(({ next, ctx }) => {
  ...
  return next({
    ctx: {
      user: ctx.session.user,
    },
  })
})

const withAuthMW = trpc.procedure.use(isAuthed).middleware(...)

instead of

const authedProcedure = trpc.procedure.use(isAuthed).use
type WithAuth = Parameters<typeof authedProcedure>[0]

const withAuthMW: WithAuth = ...

It's better if middleware can update other props.

const isAnyWithInputValidation = trpc.procedure.input(z.object({foo: z.string()})).middleware(({input, next}) => {
  const { foo } = input
  ...
  return next({...})
})

const anyProcedure = trpc.procedure.use(isAnyWithInputValidation).input(
  z.object({
    foo: z.string(),
    bar: z.number()
  })
).query(({input}) => {
  const { foo, bar } = input
  ...
})

[karmux]

I totally agree with @huzaifahj that

t.router({}).use(isAdmin)

is very much needed and I think it's a huge regression.

tRPC examples are very primitive and there it's not a big problem that can only add middleware per procedure. You have router and procedure visually in the same place.

In real life bigger projects you would put queries and mutations to separate files and then you would have to make sure that you use correct procedure in these files since it's not clear to which router they belong to. It's easy to make a mistake of putting a public procedure under admin router.

[lucashfreitas]

@karmux exactly, I am facing this problem in almost every TRPC application I develop. Usually I have 100+ routes and some of them have different middleware/procedures (admin, group level, etc). It would be much easier to define this globally at a route level than repeating that 100 times.

Easy to do a mistake and forget to apply a procedure, or apply the wrong one - that's not too bad since we have tests for that, but would be a game changer if we could apply a middleware/procedure to a group/many route items in the route level at once.

I LOVE the current implementation and flexibility, but would also be nice to define it just once at the route level than having to do it many times again and again.

This is not a new concept and some web frameworks use that strategy of defining middleware at a route level. I imagined something like this.

[KATT]

What's the problem with using base procedures? They're more composable and doesn't enforce behaviour of a procedure just because a procedure is within a certain router.

If you really feel like you need a protected router wrapper like this, you can write one. Here's an example to get you started:

function protectedRouter<TCallback extends (proc: typeof protectedProcedure) => Record<string,AnyProcedure>>(callback: TCallback) {
  return t.router(callback(protectedProcedure));
}

const user = protectedRouter(proc => ({
  whoami: proc.query(opts => {
    console.log('your user id is', opts.ctx.session.user.id)
  }),
}))

https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAb2AO2DAKgJQAoGEA0cWeAolFNIQILICe2FAxgKYAmArlMwL5wBmFEHABEAARhQwjAPQBnZlABuC4QChVjCMlnx4AXjgo0xXADpNyGMwAeMADwJVcOPNmzgWgPwAuRE+dw7PJQvo4BAcCsvjpQKADm-s7c-sncAHwAFACU5lwAhlbZANzq6hY6cGAUVoxWrAwQLBxccAYwplWNbJzMpkHMGRkQYDCyWa1pfs7AfHAZAITDo+Yw1qau7lrjYQEwABYUAO5wyMzHJmQUUBk74ZqszL7CAKoAclTP6AASAPKYAJIALRIABE1OFuFkUupnFwYJxkHAlrJTKdbDdEnBatZQpjnBsPMhfMiVmsCVp8JjkkkoapIeo+OxkLVCZVqsxamxMBB2FYoHZ0Lg8gAbYUAIzyjAA1nAbFZkKxZHNOoxfDBaGBmBBZp0anUGk0euM9JNMBzoKw7DF4vgaPQmN0uGlMowReLJVLfIK3RLpdt-HCEXB2hReQoMq7Rb6pRldRz9Q7mswslkSskNFoKv0oK02RA9VyeXzY0wJnMdoc9hA8iBgL4VaYAI7sBS0IYjJUmqYBcoQYW9YUQOIZADktB5OezhlYhlkI8IJOx62YbkJfWCpkiUJplMhtIz2ngeTAYG5YZzbVMoeLO2zu6yQA

You can choose not to expose e.g. unprotected procedures to the rest of your app so you can only use your router-helpers.

[AdventureBeard]

Sorry to gravedig, but just wanted to add: not being able to apply middleware to a namespace is a huge miss, IMO. This will prevent me from migrating to V10 just from the sheer amount of present and future maintenance this change creates. My project is designed around namespaces with certain rules, such that routes added to particular routers automatically inherit all those rules. Very easy to move fast and not break anything by just putting a route in the right place.

I understand that separating routing from middleware logic is probably the by-the-books Separation of Concerns way to do this, but imo is a big step back in actual DX. It results in a ton of duplicate code, and now every added route has a fresh chance to break auth rules by missing a middleware/pipe wrapper.

[willisplummer]

I'm just adopting tsrpc and just discovered that the ability to make an entire router password protected existed in 9 and not 10. This was pretty surprising to me and feels like a miss - I get that it is possible to use protectedProcedure when declaring each procedure but like AdventureBeard said, it feels like there's increased risk of accidentally using publicProcedure in one place and leaving an API exposed

[ahkhanjani]

Since the discussion is still open,

In my case I have a router subtree for a specific feature that now needs to check for a feature flag for the entire route. Just adding that at the router level would make it much more predictable.

It is definitely doable with a base proc as @KATT mentioned. But in my case:

1. I already have extended procs for role based routes. They are extended from a protectedProcedure.
2. Adding the feature flag layer would need the nodes to now point to this new proc.
3. Later when the feature flag is no longer needed, they need to point to the protectedProcedure like before.

It's like adding a node in the middle of a linked list and then removing it. Whereas with a router level middleware, we're just putting a wall/door in between. No need to move pieces anymore.

Depending on the size of the tree and the complexity of the procedures it can make a big difference.