Using with Nest.Js

[gax97]

Hi everyone 👋

I wonder how suitable this library is for Nest.js?
It would be awesome if we can have an example for nest js projects.

[sachinraja]

Nest does not seem like something you would use with tRPC. How do you see them working together?

[carnesen]

We are considering using tRPC with Nest.js. We like Nest.js's dependency injection but not so much how it organizes HTTP endpoints using @controller and class-validator/class-transformer for runtime data validation. We like Zod a lot better and how tRPC provides an easier path to type safety.

[KATT]

#1504 (comment)

[lkostrowski]

@carnesen you can use Zod with Nest https://docs.nestjs.com/pipes#object-schema-validation

[nirtamir2]

I notice #1511 has been resolved.
I wonder if this helps with this task.
It will help Nest.js users to have type-safe api end to end between client and server

[myesn]

tPRC looks really good and greatly improves development efficiency, but there are too many things to rewrite to adapt existing applications. Is there an easy way to make tRPC compatible with existing NestJS applications? It would be really awesome if this could be done!

[reslear]

same, wait :)

[reslear]

Is there any approximate roadmap?

[KATT]

None of the maintainers of tRPC are users of nestjs.

Therefore, we have no plans on putting in more unpaid work to support nestjs when we have no use of it ourselves - this has to come from the community or through paid consulting.

I have no idea what it would take to support nest as I'm not a user of it so I have no insight on how an adapter would look like.

---

Update: see potential workaround by @hypnodron below

[judocode]

Any updates?

[macstr1k3r]

@judocode https://github.com/macstr1k3r/trpc-nestjs-adapter

[dheerajbhaskar]

@KATT said this

I have no idea what it would take to support nest as I'm not a user of it so I have no insight on how an adapter would look like.

Then it occurred to me, nestjs uses express or fastify engines (as per user choice). Trpc already has adapters for express and fastify. So, I guess we just need to figure out a way to hook into the underlying engine with existing trpc adapters.

Of course, an example project implementation would be helpful, but this can be a starting point

[jbw]

I played around with this. I hadn't used trpc before, but I use NestJS. You could sit alongside the API layer of NestJS by creating a trpc router like:

const e = express();
const app = await NestFactory.create<NestExpressApplication>(AppModule, new ExpressAdapter(e));

e.use(
  '/trpc',
  trpcExpress.createExpressMiddleware({
    router: appRouter,
  }),
);

await app.listen(3000);

Which completely sidesteps any NestJS controllers, middleware, etc such as validation using class-validator.

But you can use DI and the module system but I imagine there are some caveats when you want to mess with injection scopes.

For example, getting an existing service and hooking that up to your router.

const appService = app.get(AppService);

t.router({
  hello: t.procedure.query(() => {
    return appService.getHello();
  }),
});

Before I started, I was thinking it would be nice to keep the NestJS controllers and see if I could pull information like routes, types, and handlers into the trpc router. But you would still lose any middleware, filters, guards, pipes, and interceptors from NestJS (so most of NestJS 😄) . Also, from the trpc docs, it looks like it has its own way of handling those concerns anyway.

In the end, I don't see much benefit in combing the two. Maybe find a DI solution for trpc.

[hypnodron]

I've recently had some experience with integrating TRPC into a NestJS project. The basic setup looks like this:

trpc.service.ts

@Injectable()
export class TRPCService {
  constructor(
    // DI provided by NestJS
    @Inject(UserRepo) private readonly userRepo: UserRepo
  ) {}

  // Singleton scope is used for injection by default so `t` is created only once
  t = initTRPC.create()

  appRouter = this.t.router({
    users: this.t.procedure.query(async (opts) => {
      // Here we can use providers injected by NestJS in our procedures 
      return this.userRepo.find()
    })  
  })
  
  applyMiddleware(app: NestExpressApplication) {
    app.use(
      "/trpc",
      createExpressMiddleware({
        router: this.appRouter,
      })
    )
  }
}

main.ts

const app = await NestFactory.create(AppModule)
const trpcService = app.get(TRPCService)
trpcService.applyMiddleware(app)

As the project grows initTRPC and child routers can be moved into their own providers (injections in constructors skipped for brevity):

trpc-init.service.ts

@Injectable()
export class TRCPInitService {
  t = initTRPC.create()
} 

trpc-users.service.ts

@Injectable()
export class TRCPUsersService {
  usersRouter = this.trpcInit.t.procedure.query(...)
} 

trpc.service.ts

@Injectable()
export class TRCPService {
  appRouter = this.trpcInit.t.router({
    users: this.trpcUsers.usersRouter
  })
} 

[LZL0]

@nllahat see https://github.com/macstr1k3r/trpc-nestjs-adapter for a solution which works with request scoped providers.

Looks great!

[AlexSua]

Maybe there is something that I am missing, but following this example:

@Injectable()
export class TRCPService {
  appRouter = this.trpcInit.t.router({
    users: this.trpcUsers.usersRouter
  })
} 

You can't use this.trpcUsers there right? I mean, you are using this.trpcUsers that comes from DI before being initialized. And if you put the appRouter in the constructor, how could you export to the client like this?:

export type AppRouter = TRPCService["appRouter"]

And this means also you can't use providers inside requests:

 appRouter = this.t.router({
   users: this.t.procedure.query(async (opts) => {
     return this.userRepo.find() //<----- this.userRepo not initialized
   })  
 })

And all of this makes me believe that you can't use DI with TRPC... which makes me wonder why would you use Nest with TRPC?

[hypnodron]

@AlexSua, the injections in constructors were skipped for brevity, the full example would look something like this:

// trpc-init.service.ts
@Injectable()
export class TRCPInitService {
  t = initTRPC.create()
} 

// trpc-users.service.ts
@Injectable()
export class TRCPUsersService {
  constructor(
    private readonly trpcInit: TRCPInitService,
  ) {}
  usersRouter = this.trpcInit.t.procedure.query(...)
} 

// trpc.service.ts
@Injectable()
export class TRCPService {
  constructor(
    private readonly trpcInit: TRCPInitService,
    private readonly trpcUsers: TRCPUsersService,
  ) {}
  appRouter = this.trpcInit.t.router({
    users: this.trpcUsers.usersRouter
  })
}

This exact approach is now also described in https://www.tomray.dev/nestjs-nextjs-trpc with more details and examples.

For new projects I would suggest to take a look at https://github.com/ts-rest/ts-rest which has first-party support for NestJS.

[AlexSua]

That was not the problem. I was using "esnext" as target in typescript compiler options and it was not allowing me to do this call:

 this.trpcInit

as it was detecting that it was a non initialized variable. I changed the target to "ES2022" and now it works. My bad.

I believed as well it was not possible to do this call:

  appRouter = this.trpcInit.t.router({
    users: this.trpcUsers.usersRouter
  })

since in my head this part of the code was executed before the constructor.

[iceStorm]

I was recently also facing this problem. I'm specifying ESNext for the entire app. To fix the above issue, I ended up using this solution: microsoft/TypeScript#53286 (comment)

TLDR;
Set useDefineForClassFields: false inside tsconfig of the NestJS app.

[Brokerful]

hi, how would you use it on the client side?

[reslear]

in monorepo api package

[macstr1k3r]

Hi,

I've built an adapter that will enable you to use tRPC with Nest.JS.

have a look at it, and if it gains some traction I'll work on documenting it properly.

https://github.com/macstr1k3r/trpc-nestjs-adapter

[dzcpy]

Looks cool!
I wonder where should I put code like below into a project?

[macstr1k3r]

It's kinda up to you.

Nest.JS's interpretation of controllers vastly differs from tRPC's.

I use some form of domain oriented folder structure, so in every domain folder I introduced 2 folders, queries and mutations.

All of those are gathered in a domain router which I later on connect to the root tRPC router.

The end result is roughly.
trpcClient.domainRouter.query

In the future I intend to export the zod schemas separately so that I can import them on the front-end and use them to validate forms, where applicable.

[samchon]

What about using nestia in NestJS?

It can generate SDK library and the SDK library can be same thing like createTRPCProxyClient of trpc.

[yousif-khalil-abdulkarim]

You coudl try use typedi standalone depdency injection library or only use nest js as depedency injection library

[sannajammeh]

ts-rest was made specifically for allowing this type of task. Very similar to tRPC

[dzcpy]

ts-rest seems to be pretty cool. Thanks for sharing!

[firxworx]

@dzcpy also check out https://www.zodios.org/ - typescript http client and server with zod validation

[robert-king]

we're using ts-rest, pretty nice especially with NX

[cloudever]

If someone would like to write typed end-to-end microservices using nestjs, just use following approach, same implemented in trpc using js proxies

Gateway side:

import type { UsersService } from '@myproject/users-service' // <-- here we just import types, not all
import { InjectClientServiceProxy } from '../decorators'

@Resolver()
export class ExchangeDirectionResolver {
  // Please note that `USERS_SERVICE` - is just a token defined in ClientsModule
  @InjectClientServiceProxy({ name: "USERS_SERVICE" })
  private readonly usersService: UsersService

  @Query()
  async getUser(@Args() id: string) {
    return this.usersService.users.getById(id)
  }
}

And @InjectClientServiceProxy decorator that uses power of proxies

import { ClientProxy } from '@nestjs/microservices'
import { Inject, HttpException, HttpStatus } from '@nestjs/common'
import DeepProxy from 'proxy-deep'

export const InjectClientServiceProxy =
  (options: { name: string }): PropertyDecorator =>
  (target, property) => {
    const clientProperty = `${String(property)}__client`

    Inject(options.name)(target, clientProperty)

    let getInstance = () => {} // <-- that might be anti-pattern but I've not found any other solutions to class instance

    const proxy = new DeepProxy(
      {},
      {
        get() {
          return this.nest(function () {})
        },
        apply(this, applyTarget, thisArg, args) {
          const promise = (getInstance()[clientProperty] as ClientProxy)
            .send(this.path.join('.'), args[0])
            .toPromise()

          return promise
        },
      }
    )

    Object.defineProperty(target, property, {
      get() {
        getInstance = () => {
          return this
        }

        return proxy
      },
    })
  }

Microservice side

UsersService is a class that bootstap all data-access services in users microservice

@Injectable()
@RegisterGlobalServiceContoller() // <-- does some magic
export class UsersService {
  @Inject(UserServiceDatabase)
  readonly users: UserServiceDatabase // <-- its a simple class with crud
  
  // here might be other data-access service just like `tokenService`, `resetPasswordService`

And RegisterGlobalServiceContoller decorator looks like:

export const RegisterGlobalServiceContoller =
  (): ClassDecorator => (Target) => {
    const metadata: { key: string; type: any }[] = Reflect.getMetadata(
      PROPERTY_DEPS_METADATA, // <-- imported from nestjs, thanks to nest runtime
      Target
    )

    metadata.forEach((meta) => {
      Controller()(meta.type) // <-- make data-access-service a controller else it cant be scanned by nestjs runtime

      Object.getOwnPropertyNames(meta.type.prototype).forEach((property) => {
        if (property === 'constructor') {
          return
        }

        MessagePattern(`${meta.key}.${property}`)(
          meta.type,
          property,
          Object.getOwnPropertyDescriptor(meta.type.prototype, property)
        )
      })
    })
  }

Don't forget that you must export type UsersService from main.ts and define all data-access-services in module controllers: [...]

Troubles

1. Do not use arrow style function in data-access service, else it cant be found by RegisterGlobalServiceContoller.
2. There must be only 1 argument in function calls between microservices

[Amuleus]

I wonder how suitable this library is for Nest.js?

Surely possible. Please check a great tutorial from Tom Ray:
https://www.tomray.dev/nestjs-nextjs-trpc
https://github.com/tomwray13/nestjs-nextjs-trpc

[sannajammeh]

Just going to add that if you're not in need of Nest's DI system you can just bypass it all together by running your own instance of express or fastify and passing it into the Nest.js factory.

	await fastify.register(fastifyTRPCPlugin as any, {
		prefix: "/trpc",
		trpcOptions: {
			router: appRouter,
			createContext: async (opts: CreateFastifyContextOptions) => {
				// Init payload
				return await trpcInnerContext({
					...opts,
					prisma,
					payload: initializedPayload,
					supabase,
					revenueCat,
				});
			},
		},
	});

	const nest = await NestFactory.create<NestFastifyApplication>(
		AppModule,
		new FastifyAdapter(fastify as any), // Type conflicts here
	);

[merthanmerter]

None of the maintainers of tRPC are users of nestjs.

Therefore, we have no plans on putting in more unpaid work to support nestjs when we have no use of it ourselves - this has to come from the community or through paid consulting.

I have no idea what it would take to support nest as I'm not a user of it so I have no insight on how an adapter would look like.

---

Update: see potential workaround by @hypnodron below

sorry but remove this section from your website then;

Framework agnostic
Compatible with all JavaScript frameworks and runtimes. It's easy to add to your existing projects.