tRPC•3mo ago

creating middleware with context type as param

i'm looking into build a "post operation" function into separate piece of code. i know it may be done differently but i'm looking into it for code structure purpose. the goal of the middleware is to accept a function which takes the current context as input, as well as the result from the handler, and execute code.

import type { MiddlewareResult } from '@trpc/server'
import { initTRPC } from '@trpc/server'

import type { Context } from '../context'

type Action<C, R> = (opts: {
  ctx: C
  result: MiddlewareResult<R>
}) => unknown | Promise<unknown>

export function post<C, R>(action: Action<C, R>) {
  const t = initTRPC.context<Pick<Context, 'get'>>().create()

  return t.procedure
    .use(async ({ ctx, next }) => {
      const result = await next()

      action({ ctx, result })

      return result
    })
}

import type { MiddlewareResult } from '@trpc/server'
import { initTRPC } from '@trpc/server'

import type { Context } from '../context'

type Action<C, R> = (opts: {
  ctx: C
  result: MiddlewareResult<R>
}) => unknown | Promise<unknown>

export function post<C, R>(action: Action<C, R>) {
  const t = initTRPC.context<Pick<Context, 'get'>>().create()

  return t.procedure
    .use(async ({ ctx, next }) => {
      const result = await next()

      action({ ctx, result })

      return result
    })
}

import type { MiddlewareResult } from '@trpc/server'
import { initTRPC } from '@trpc/server'

import type { Context } from '../context'

type Action<C, R> = (opts: {
  ctx: C
  result: MiddlewareResult<R>
}) => unknown | Promise<unknown>

export function post<C, R>(action: Action<C, R>) {
  const t = initTRPC.context<Pick<Context, 'get'>>().create()

  return t.procedure
    .use(async ({ ctx, next }) => {
      const result = await next()

      action({ ctx, result })

      return result
    })
}

import type { MiddlewareResult } from '@trpc/server'
import { initTRPC } from '@trpc/server'

import type { Context } from '../context'

type Action<C, R> = (opts: {
  ctx: C
  result: MiddlewareResult<R>
}) => unknown | Promise<unknown>

export function post<C, R>(action: Action<C, R>) {
  const t = initTRPC.context<Pick<Context, 'get'>>().create()

  return t.procedure
    .use(async ({ ctx, next }) => {
      const result = await next()

      action({ ctx, result })

      return result
    })
}

my problems are:

i have no idea how to get the
```
C
```
C
```
C
```
C
(context) type right
the
```
MiddlewareResult<>
```
MiddlewareResult<>
```
MiddlewareResult<>
```
MiddlewareResult<>
type is not exposed from
```
@trpc/server
```
@trpc/server
```
@trpc/server
```
@trpc/server
so i can't pull it.

my questions are:

can it be done?
how difficult it should be?
somebody has pointer on it? help please

thanks

Nick•9/18/25, 9:07 AM

Would “standalone middleware” fit your needs here?

Nick•9/18/25, 9:07 AM

Sounds like you’re trying to reproduce that

y_nkOP•9/22/25, 4:52 AM

@Nick Lucas yes and no. what i'm doing is the same as standalone middleware but with reusable procedure instead as standalone middlewares are deprecated (as per docs)

y_nkOP•9/22/25, 4:53 AM

y_nkOP•9/22/25, 4:54 AM

the difficulty that i'm having is that i would like to have the result type of the operation carried as well and it seems not possible

y_nkOP•9/22/25, 5:03 AM

when using, at the time of building the procedure, it's impossible to get the returned type of the operation since .concat().concat() is only before .query().query(), .mutation().mutation() and .subscription().subscription() but not available after. so i'm 90% sure it's impossible :/ @Alex / KATT

would maybe confirm this easily

y_nkOP•9/22/25, 5:05 AM

someProc: asPublic
  .concat(
    post(
      async ({ result }) => {
        console.log(result.foo) // <- pretty sure we can't grab the type of result before .query
      }
    )
  )
  .query(
    async () => ({ foo: 'foo' })
  )

someProc: asPublic
  .concat(
    post(
      async ({ result }) => {
        console.log(result.foo) // <- pretty sure we can't grab the type of result before .query
      }
    )
  )
  .query(
    async () => ({ foo: 'foo' })
  )

y_nkOP•9/22/25, 5:06 AM

and this also not possible

someProc: asPublic
  .mutation(
    async () => ({ foo: 'foo' })
  )
  .concat( // <- can't chain after an op
    post(
      async ({ result }) => {
        console.log(result.foo) // <- insert to audit log op, dispatch mutation to event bus
      }
    )
  )

someProc: asPublic
  .mutation(
    async () => ({ foo: 'foo' })
  )
  .concat( // <- can't chain after an op
    post(
      async ({ result }) => {
        console.log(result.foo) // <- insert to audit log op, dispatch mutation to event bus
      }
    )
  )

y_nkOP•9/22/25, 5:22 AM

only way i can think of is wrapping the whole procedure just to capture the return type in a generic but i can't even start to understand how to type it correctly

import type { ProcedureBuilder } from '@trpc/server/unstable-core-do-not-import'

function post<P extends ProcedureBuilder<
  TContext,
  TMeta,
  TContextOverrides,
  TInputIn,
  TInputOut,
  TOutputIn,
  TOutputOut,
  TCaller
>>(
  proc: P,
  handler: (opts: { ctx: ???, result: ??? }) => Promise<void> | void,
) {
  return proc.use(async ({ ctx, next }) => {
    const result = await next();
    setTimeout(() => handler({ ctx, result }), 0); // run after
    return result;
  });
}

// usage
const router = {
  someProc: post(
    asPublic
      .mutation(
        () => { foo: 'foo' }
      ),
    async ({ result }) => {
      if (result.ok) {
        console.log(result.data.foo) // typed
      }
    },
  ),
});

import type { ProcedureBuilder } from '@trpc/server/unstable-core-do-not-import'

function post<P extends ProcedureBuilder<
  TContext,
  TMeta,
  TContextOverrides,
  TInputIn,
  TInputOut,
  TOutputIn,
  TOutputOut,
  TCaller
>>(
  proc: P,
  handler: (opts: { ctx: ???, result: ??? }) => Promise<void> | void,
) {
  return proc.use(async ({ ctx, next }) => {
    const result = await next();
    setTimeout(() => handler({ ctx, result }), 0); // run after
    return result;
  });
}

// usage
const router = {
  someProc: post(
    asPublic
      .mutation(
        () => { foo: 'foo' }
      ),
    async ({ result }) => {
      if (result.ok) {
        console.log(result.data.foo) // typed
      }
    },
  ),
});

y_nkOP•9/22/25, 5:25 AM

and even like this, it's kinda ugly

y_nkOP•9/22/25, 5:52 AM

i've tried to read source code of trpc to know if that could be implemented but it's unlikely. we'd need to have createResolver not to create a resolver but another kind of builder which returns either the created resolver or a post action which returns the resolver.

y_nkOP•9/22/25, 5:53 AM

since the builder pattern is well made and atomic, it's equally impossible to "patch" anything because it's neat and tight. otherwise i'd have to patch every return of createNewBuildercreateNewBuilder and implement my own

query

query

mutation

mutation

and subscriptionsubscription

y_nkOP•9/22/25, 5:53 AM

i'm pretty sure i'd loose typing in the process

y_nkOP•9/22/25, 5:53 AM

so i guess the "wrapper" is the least ugly of all

Alex / KATT 🐱•9/22/25, 8:02 AM

here's a quick and dirty version: https://github.com/trpc/trpc/compare/09-22-post-proc?expand=1

Alex / KATT 🐱•9/22/25, 8:04 AM

there's probably a way to wrap the whole procedure and not just the resolver at the end, but i don't have time to figure out how to do that

Alex / KATT 🐱•9/22/25, 8:10 AM

actually it wasn't that hard, i added that too

y_nkOP•9/24/25, 2:18 AM

thanks a lot @Alex / KATT

, indeed the solution is damn simple i don't know why i didn't figure it out myself

y_nkOP•9/24/25, 2:23 AM

i guess i was stuck into trying to explicitly pass ctx and result types but didn't think to just carry them all with the function itself

y_nkOP•9/25/25, 2:38 AM

@Alex / KATT

would you see this as a useful chain after queries and mutations? we have "before-ish" middlewares, but how about post ones? as a lib feature, i meant. i wouldn't mind trying if you thought it's worth it.

Alex / KATT 🐱•9/27/25, 6:23 AM

Not sure, I still don't understand why you need it

y_nkOP•9/30/25, 8:22 AM

i want to handle my api and return the payload asap, but at the same time have the mutation advertised in a message queue after the response is delivered

y_nkOP•9/30/25, 8:23 AM

(doesn't need to be awaited)

y_nkOP•9/30/25, 8:23 AM

i could very much put it inside the handler directly but having to handle success/error case on top makes the handler "clogged with non handler primary logic"