Editor performance issues in large codebases

[tonyxiao]

Using https://github.com/astahmer/openapi-zod-client and example schema https://api.merge.dev/api/accounting/v1/schema, we generated a zodios file that is about 5k lines long. At this length it seems that the autocomplete works only after a very significant lag, making it really difficult to use zodios. Does this happen to anyone else? Are there ways we can make the performance better?

[ecyrbe]

Hello,
I'll migrate this into Q&A because we are wrapping the limits of typescript there (not an issue i can address)
So here are some thoughs:

• if you can, remove all the endpoints and schema you don't need on your code
• Split it into different files and different client zodios instance / like put a client for each resources (if you have isolated modules ts perf will go up)

[ecyrbe]

But i have big performances issues with full airbyte api. it's unsuable without splitting defintions. My guess is that the filtering takes too much time. but i'll investigate why typescript is so slow at filtering.

[tonyxiao]

The first issue is due to the fact that now the body has to be filled in the body property. There is no more a distinct function parameter for body.

I tried it but the body property is coming out to be unknown

[AntoineThibi]

I had the same issue of editor performance and I tried the version 11.0.0-beta.19. It seems to reduce by about 50% the typescript time.

However, I had an issue getting to the instance of axios in order to had interceptor.

import { Zodios } from "@zodios/axios";
import { makeApi } from "@zodios/core";

const Endpoints = makeApi(myEndpoints);

export const myApi = new Zodios(Endpoints, {
  axiosConfig: {
    baseUrl: 'myurl'
  }
});

// Previously I did : 
myApi.axios.interceptors.request.use(....)

// Now after looking at the typing : 
myApi._fetcherProvider.options.axiosInstance.interceptors.request.use(.....)
// However while running it I find that _fetcherProvider is undefined

Do you have any idea were it can come from ?

[ecyrbe]

Axios is no more exposed as zodios v11 is now fetcher agnostic.
Either pass your own instance of axios and plug your interceptors in your custom axios instance or better use zodios plugins they are the same:
https://www.zodios.org/docs/client/plugins#write-your-own-plugin

[jordanmnunez]

@ecyrbe We are migrating to v11-beta to fix these same editor issues and are are seeing solid improvements as well (50% reduction in type compiles). However, we were also borrowing some typing from v10 that are hard to track down now.
For example: import type { ZodiosAliases } from "@zodios/core/lib/zodios.types"; and import { ZodiosError, zodValidationPlugin } from "@zodios/core";

Can you please share any updated docs or links to source code for v11-beta. I have been unable to track them down.

[Dimava]

I strongly think this is caused by Zodios using type-level array.find({ path }) rather then record[path], leading to O(m*n) rather then O(M + n)

[Dimava]

TS won't recompile record once it's compiled, (so big M), but will iterate array because it has to (so m*n)

[ecyrbe]

No, no,
We don't have double loops in find, so complexity is also additive with arrays
The diff with array vs record is O(1) vs O(N)
So we have O(M+N) vs O(N)

[Dimava]

I mean, if there are N routes

• the instantiation of const Record<route, Route> will take O(N)
  • the search in Record<route, Route> will take O(1)
    • the search for every route will take O(N)
• the instantiation of const Route[] will take O(N)
  • the search in Route[] will take O(N)
    • the search for every route will take O(N*N)

[Dimava]

ArkType has type instantiation benchmark, which could be used in the future

ArkType's type performance is an order of magnitude better then Zod's exactly because it's made as efficiently as possible.
I think it would make sence to compare type instantiation performance of TRPC/ts-rest/Zodios as they are generally equivalent

[antonio-ivanovski]

We were facing severe performance issues for a fairly small application with Zodios v10, so I tried to migrate to v11. Here are some findings:

1. 🟢 Resolutions and autocomplete are almost instantaneous. From the previous ~10 seconds to even timing out and failing to resolve the type, currently, it is <200ms.
2. 🟢 The isErrorFromPath and isErrorFromAlias has been removed from utility kind to ZodiosInstance method
3. 🟢 Making requests is cleaner by having both body and params properties in the method.
4. 🟢 Server side ZodiosRequestHandler is 1 to 1 mapped to ZodiosPathMiddleware.
5. 🟡 Missing the paramtersBuilder utility in the beta.19, resorting back to makeParameters.
6. 🟡 Dynamic setting of headers is a bit harder since method calls don't have direct access to headers. The workaround is either using AxiosRequestTransformer or defining the header as a parameter for all endpoints.
7. 🟡 Endpoint descriptions have the method of 'OPTIONS' removed.
8. 🔴 Plugins package has not yet migrated to v11. The tokenPlugin still works 🤞.
9. 🔴 The isErrorFromAlias and isErrorFromPath don't work with Beta 19 version for endpoints with path params Feature/v11 #237 (comment)

@ecyrbe keep up the good work 👏. Any info on another beta release or v11 stable release?

[jordanmnunez]

+1 on all these feedback @ToTeTo. Excited to hear an update as well.

[corneliusroemer]

Are there still plans for v11?