Resources for improving typescript performance?

[iway1]

Our project is at about 40 end points using tRPC V9 with react and we're experiencing a pretty substantial slowdown of typescript. Mutations in particular are excruciatingly slow at this point. We're using zod schemas for both input and output, if that matters.

Are there any guidelines or resources for potentially restructuring our project or something in order to improve TS performance? I know V10 should significantly improve performance but we're needing to do a lot of work with V9 before it is released.

Edit: Have been trying a few different things to try to speed up performance. I'm not having any luck speeding up intellisense, but I was able to start typescript in watch mode which type checks much faster (about 3 seconds instead of like 15). It pretty much has all the same benefits as the intellisense version, other than autocomplete (autocomplete isn't having bad performance), just will have to get used to looking at the console. 3 seconds is fine by me for now, it's still light years faster than having to open a swagger doc or something.

There are some options that are pretty much required to have decent compile times, specifically skipLibCheck and incremental being set too true. There may be some other ways to improve performance as well with the conifg.

I'll keep looking into ways to potentially improve performance. Hopefully at some point we can have some sort of documentation on how to deal with this sort of thing in the context of tRPC.

[sachinraja]

What you've tried sounds like the best ways to improve performance for v9. You could also try the v10 alpha but you'd be susceptible to any changes.

Another thing you can try is project references but that's much more complicated.

[iway1]

So just an update on this -

Our number of endpoints continued to grow, and eventually typescript just died. We got a "type instantiation is excessively deep" error past a certain number of end points, which makes it unusable.

However, I came up with a hack that allows us to fix typescript in a way that allows it to scale to any number of end points, but it is slightly more complex.

Basically the idea is you split the type into multiple routers, then you have a custom hook that uses the react query hooked typed to just one router. So you end up with a bunch of different useQuery hooks, each that only knows about the type for one router. IE you'd have

useUserQuery
useCommentsQuery
useToDoQuery

And each one of those hooks only has the type for one router.

Not ideal, but does fix the typescript issues we're facing and we still get all the benefits of using tRPC.

Not too upset with this solution, at least I can have peace of mind that our typescript will scale now (as long as our routers are sized reasonably). Plus it'll fix the slowdowns.

Going to implement this fully on Monday when I'm back on the project, I'll post the solution here in case anyone else needs to fix this in V9

[iway1]

Alright the hack seems to work really well once everything's set up, our typescript performance is good again and can now scale to any size as long as individual routers don't become too big.

Here's the exact function we're using:

export function createTrpcQueryHook<RouterType extends Router<any, any, any, any, any, any, any>>(routerName: string) {
    const d = createReactQueryHooks<RouterType>();

    function useQuery(...args: Parameters<typeof d['useQuery']>) {
        //@ts-ignore
        return d.useQuery([routerName + args[0][0], ...args[0].slice(1)], ...args.slice(1))
    }

    function useMutation(...args: Parameters<typeof d['useMutation']>) {
        //@ts-ignore
        return d.useMutation(routerName + (Array.isArray(args[0]) ? args[0][0] : args[0]), ...args.slice(1));
    }

    return [
        useQuery as typeof d.useQuery,
        useMutation as typeof d.useMutation,
    ] as const
}

Note that we really only are calling createReactQueryHooks to get a typed version of useQuery with the correct types for that one router, and then we prepend the router name manually.

Then we call it like:

export const [useAdminQuery, useAdminMutation] = createTrpcQueryHook<AdminRouter>('admin.');

Where AdminRouter is one of the routers that gets merged with the main app router. Now we have a useAdminQuery hook that contains just the end points of the admin router.

It's not perfect and there are some small issues, but ultimately it's a small price to pay to get our typescript working well with tRPC V9.

We're having to call createReactQueryHooks multiple times, and since we actually aren't using a lot of the stuff that it generates it seems wasteful. there's probably a solution that involves typecasting without calling it (we're calling a JS function to generate a type after all, that seems unnecessary). Also, I'm not good enough at typescript to get around the ts-ignore.

Lastly, we have to make sure the router name we pass to createTrpcQueryHook matches what's on the backend.

I know it's a bona fide hack, but I'm honestly pretty happy with the outcome. I can sleep easy knowing my typescript performance won't sh*t the bed in V9.

If anyone knows how to type cast the useQuery to a certain router type without calling createReactQueryHooks, that'd be sweet.

If it helps, our actual router looks like this:

export const appRouter = createRouter()
    .merge('admin.', adminRouter)
    .merge('auth.', authRouter)
    .merge('fan.', fanRouter)
    .merge('media.', mediaRouter)
    .merge('notification.', notificationRouter)
    .merge('performer.', performerRouter)
    .merge('user.', userRouter)
    .merge('utility.', utilityRouter);

export type AdminRouter = typeof adminRouter;
export type AuthRouter = typeof authRouter;
export type FanRouter = typeof fanRouter;
export type MediaRouter = typeof mediaRouter;
export type NotificationRouter = typeof notificationRouter;
export type PerformerRouter = typeof performerRouter;
export type UserRouter = typeof userRouter;
export type UtilityRouter = typeof utilityRouter;

[iway1]

Alright so one last followup just in case anyone sees this thread in the future.

The above solution ended up breaking down on us as well. The auto complete / intellisense became so slow that it was pretty much impossible to write code (since auto imports rely on intellisense, it's blocking to wait on it).

So, we had to get our auto imports back so the first thing we did was use any as the router. Of course this turns off all typesafety, which sucks a lot, but we had to write code. To maintain some semblance of typesafety we were importing types directly from the backend. This fixed performance issues, allowed us to write our code, but also left a lot of room for developer error.

Eventually we came up with a solution for explicitly typing everything that gives us that sweet, sweet full stack type safety. Basically we just manually maintain our own definitions of routers now that look like this, for example:

export type UserRouterDefinition = {
    queries: {
        getLoggedInUser: {
            input: EmptyInput
            output: UserOutput
        }
        deleteLoggedInUser: {
            input: EmptyInput
            output: MessageOutput
        }
    }
    mutations: {
        updateLoggedInUser: {
            input: UpdateLoggedInUserInput
            output: UserOutput
        }
        updateLoggedInUserPassword: {
            input: UpdateUserPasswordInput
            output: MessageOutput
        }
    }
}

So this is extra overhead, it's worse than getting it for free like you do when tRPC is functioning properly, but we had to do it because our intellisense died completely which blocked all front end development. Each router requires it's own custom hooks (although we probably could have just one big router):

import { createTrpcQueryHook } from "src/trpc/query-hooks/create-trpc-query-hook";
import { QueryOptions, UseMutationOptions, UseMutationResult, UseQueryOptions, UseQueryResult } from "react-query";
import { UserRouterDefinition } from "src/trpc/routers/User.router.definition";
import { useTrpcContext } from "src/trpc";

const [_useQuery, _useMutation] = createTrpcQueryHook('prefix.');

export function useUserQuery<Path extends keyof UserRouterDefinition['queries']>(pathAndInput: [Path, UserRouterDefinition['queries'][Path]['input']], options?: UseQueryOptions) {
    return _useQuery(pathAndInput, options) as UseQueryResult<UserRouterDefinition['queries'][Path]['output']>;
}

export function useUserMutation<Path extends keyof UserRouterDefinition['mutations']>(args: [Path] | Path, options?: UseMutationOptions) {
    return _useMutation(args, options as any) as UseMutationResult<UserRouterDefinition['mutations'][Path]['output'], unknown, UserRouterDefinition['mutations'][Path]['input']>;
}

export function useUserInvalidateQuery() {
    const context = useTrpcContext();
    return <Path extends keyof UserRouterDefinition['queries']>(pathAndInput: [Path, UserRouterDefinition['queries'][Path]['input']]) => {
        const path = 'user.' + pathAndInput[0];
        context.invalidateQueries([path, pathAndInput[1]])
    }
}

export function useUserSetQueryData() {
    const context = useTrpcContext();
    return <Path extends keyof UserRouterDefinition['queries']>(pathAndInput: [Path, UserRouterDefinition['queries'][Path]['input']], updater: (old: UserRouterDefinition['queries'][Path]['output'] | undefined) => (UserRouterDefinition['queries'][Path]['output'] | undefined)) => {
        //@ts-ignore
        context.setQueryData(pathAndInput, updater)
    }
}

This might look like a lot to maintain at first glance, but we actually were able to create a script that auto generated all these custom hooks per router. The end result is that we now have to maintain these so called "router definition" files (so adding one additional property to the definition per endpoint), and run a command any time we make changes to generate the hooks yarn generatehook. It's a little bit of extra overhead, but we're getting spectacular autocomplete performance now with very cheap full stack type safety.

Just for additional context:

• The reason we have to stick with V9 for now is that trpc-open-api is a requirement, and it requires V9 as it doesn't support V10 yet.
• We're using a lot of zod schemas that are composed of other zod schemas using things like .pick and .merge, which may be contributing to the severe typescript performance issues we were experiencing since zod is an entire other layer of type inference. However, these composition based schemas are probably the right solution because of the high degree of maintainability they allow (changes to a type propagate to all types of any composed types).
• We didn't have that many endpoints per router, like 20 or so, and were still experiencing these issues

Additionally I just want to point out how serious slow intellisense performance is as an issue: If your intellisense is loading, you are blocked. If your intellisense slows down signficantly, you are really, really screwed, it's a complete disaster. I didn't realize before this experience how necessary of a tool intellisense is, but it really is a worst case scenario as far as developer productivity goes. Auto imports in particular are absolutely necessary when building anything new. Can't let intellisense slowdowns happen and they have to be avoided at all costs.

Anyways, not saying anyone should or shouldn't use tRPC V9, but it's worth documenting that severe enough performance issues can happen such that type inference has to be disabled. I'm still glad I used it, because it pushed our team towards full stack type safety and now we have a highly maintainable codebase (plus it forced me to get better at typescript =D).

There was no previous documentation on how to "opt-out" of inference as an escape hatch for these issues, so we had to create one in our case, and it's really not much extra effort in the grand scheme of things versus vanilla tRPC with high typescript performance.

[DevMude]

@iway1 thank you so much for posting all this information. Just wondering if you've migrated to v10 yet? If so, what do those changes look like to this setup?

Cannot agree more with slow intellisense speed being a blocker to developer productivity. I've put so much effort into splitting my back-end and front-end via typescript project references to no avail. I now believe it's simply because the trpc router is so large. My root router is made up of 6 routers with about 10-15 procedures each and intellisense is taking ~5s for every change made to a tsx file.

[divmgl]

This is unfortuantely still happening in v10. Also running into the slowdown issue and seemingly nothing is helping. @DevMude did you ever figure this out? Getting potentially worried at this point...

[DevMude]

@divmgl unfortunately no, the project finished up so didn't worry about trying to properly fix it. I tried measuring performance of type compilation using Performance Tracing. However I found the output quite hard to analyze and couldn't figure out how to make the appropriate changes to my codebase to improve performance.

I haven't tried this yet, but you could also try benchmarking your types using a new tool ArkType Test. Here's a video by Theo explaining the tool.

[Brenndoerfer]

I am also noticing a significant slowdown using tRPC with only a few endpoints (using Nx, too). I have a fully beefed out Macbook Pro, and it still is excruciating slow. I can't imagine how this is supposed to "work" for anyone.

I imagine that everyone regularly runs into this problem.
At this point I am afraid to invest more time into tRPC, as I foresee it breaking (TS server failing) or making user experience horrible.

Is there any advice?

[sachinraja]

What version are you on? How many endpoints do you have?

Do you have a reproduction?

You could try project references but you shouldn't need them if you only have a few endpoints.

[Brenndoerfer]

I had a performance issue during my initial evaluation of tRPC. After a bit more back and forth, I created a new project (clean slate) that caused no performance issues anymore. I am not sure why.

With 100+ endpoints, and a relatively complex tooling and code base, (nx monorepo), we don't have any performance issues anymore.

I am using v10

[AlonMiz]

having the same slowness as well. for a quite small project, 15 routes with small to medium queries/mutations (1-5)
I wonder how is this working for anyone :/
using drizzle and zod...
and trpc 11.0.0-next-beta.318
no crashing but when trying to access routes it can take several seconds to get the autocomplete

[divmgl]

@AlonMiz my hunch: this is all related to Zod. Zod creates complex types when you use extend omit pick merge and any other method that mutates the underlying type. It's super unfortunate. We're also running into major slowdowns but we have nothing to switch to. Typebox does not work the same way as Zod does and requires a lot of custom work to get going with tRPC.

[timlgl]

We could improve our situation significantly. As with a lot of you, DX became abysmal with really slow autocomplete.

Setup:

• no crazy amount of routers (<20) and routes
• we're using zod, but no heavy use of unions / intersections
• monorepo

The following steps helped:

1. Removal of "context bloat"

We had added a few heavy objects to the context in the definition of our procedures (namely, supabase client). This caused extremely large type definitions for every single route.
Removing these objects from the context, simplified the Router Type tremendously. (Alternatively, you could define a simplified type with the relevant properties)

We identified this problem with the next step:

2. Type Generation

Initially, we wanted to use xtrp. However, we had problems that were hard to investigate, so we went with a basic tsc command to generate the types for the relevant part of the application.
The generated type is now used as type for our approuter

By analyzing the generated files we had initially identified the context bloat.

This comes with the obvious drawback of having to generate the types regularly. With a proper setup not an issue for us, though.

3. inferRouterInputs and inferRouterOutputs on subrouters only.

When infering Inputs / Outputs, we found it to be way faster to got for the router directly, rather than using the main router as entry point. E.g:

Instead of inferRouterOutputs<AppRouter>["some"]["subRouter"]["get"]
we use inferRouterOutputs<SubRouter>["get"]

This way, we can even access inferred types of the subrouters and only have to rely on the generated type for the trpc client itself.

4. (not sure about this one) Explicit type definition for complex queries.

We are using kysely and have some pretty complex queries. For the most extreme cases we helped out a bit by explicitly defining the return types of those functions.
As indicated, not sure whether this had actually any impact.

I am aware that this appoach comes with some drawbacks, but at least we don't have time to get a coffee everytime we wait for intellisense to make some suggestions 😆, as they basically come instantly now.

I hope this will give some of you some pointers of what to do next. If you need some clarifications / more details, I am happy to provide more information, as this may save some severe frustration ;)

[lithdew]

Curious, how did you get the tsc command to solely generate the type for AppRouter?

[timlgl]

@lithdew As presumably most code bases, we have all routers in a subdirectory. Here we have a separate file tsconfig.trpc.json mit "outDir": "./types".

In our package json we then just added a "bake" script:

    "trpc:bake": "pnpm run trpc:clean && pnpm run trpc:generate",
    "trpc:generate": "npx -p typescript tsc --project ./routers/tsconfig.trpc.json",
    "trpc:clean": "rm -rf ./routers/types"

Dependencies of the routers will also be generated.

[jthomaschewski]

Thanks @timlgl, this approach reduced autocomplete latency from ~6 seconds down to ~0.5 seconds for me.
(of course depends on the project and hardware).

Unfortunately "go to definition" to trpc router definition does not work anymore (it will navigate to the declaration file instead).
Still worth it for me.

[divmgl]

Unfortunately "go to definition" to trpc router definition does not work anymore (it will navigate to the declaration file instead).
Still worth it for me.

You don't need an additional build step. You can use disableSourceOfProjectReferenceRedirect to get the same speed improvement. But yes, you lose the ability to see project reference redirects.

[masterbater]

Just upgrade your ram to minimum 32gb and everything will be a breeze

…

On Fri, Apr 5, 2024 at 4:16 PM timlgl ***@***.***> wrote: @lithdew <https://github.com/lithdew> As presumably most code bases, we have all routers in a subdirectory. Here we have a separate file tsconfig.trpc.json mit "outDir": "./types". In our package json we then just added a "bake" script: "trpc:bake": "pnpm run trpc:clean && pnpm run trpc:generate", "trpc:generate": "npx -p typescript tsc --project ./routers/tsconfig.trpc.json", "trpc:clean": "rm -rf ./routers/types" Dependencies of the routers will also be generated. — Reply to this email directly, view it on GitHub <#2448 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI6VFD7U7FAMESBFPEHZILY3ZMWRAVCNFSM56NIM7JKU5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSMBRHA2TQOI> . You are receiving this because you commented.Message ID: ***@***.***>

[lithdew]

I’ve got 64gb and it takes 7 seconds for autocomplete to come up with 32 routes 😅.

[masterbater]

Could be because of prisma or drizzle, there are techniques to optimize those orm

…

On Fri, Apr 5, 2024 at 8:12 PM Kenta Iwasaki ***@***.***> wrote: I’ve got 64gb and it takes 7 seconds for autocomplete to come up with 32 routes 😅. — Reply to this email directly, view it on GitHub <#2448 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI6VFB37C5L6CKXKZAXZF3Y32IKNAVCNFSM56NIM7JKU5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSMBSGA4DONQ> . You are receiving this because you commented.Message ID: ***@***.***>

[lithdew]

I'm using Kysely - the output types of Kysely are quite minimal.