Generated runtime validations (zod, io-ts, ...) are not validating/parsing the response

[Colmea]

Hi @astahmer,

Sorry for 2 issues in one day 🥲

I would like to use this library because of the runtime validation support (zod mainly) it provides.

Based on this from README

you can also generate a client with runtime validation using one of the following runtimes

I would expect that the generated ApiClient actually uses these zod schemas and parse the response with them, but it looks like it's note the case.

See the generated GET request here. It never uses the generated zod schema.

  // <ApiClient.get>
  get<Path extends keyof GetEndpoints, TEndpoint extends GetEndpoints[Path]>(
    path: Path,
    ...params: MaybeOptionalArg<z.infer<TEndpoint['parameters']>>
  ): Promise<z.infer<TEndpoint['response']>> {
    return this.fetcher('get', this.baseUrl + path, params[0]) as Promise<
      z.infer<TEndpoint['response']>
    >;
  }
  // </ApiClient.get>

Am I missing something ? Or are we just supposed to use the generated zod schemas on our own (if so, why not directly use them in the ApiClient ?)

Thanks for your help!

[astahmer]

I don't want to have to maintain that kind of code, the main goal of that lib is having a typed api client using openapi
the runtime validation is a nice bonus

if you want runtime validation from openapi + zod, there's openapi-zod-client that I made specifically for this
https://openapi-zod-client.vercel.app/

feel free to make your own api client like this one #19 (comment)
see prev discussions on the topic
#18 (comment)
#3 (comment)

I'm open to merging an API client implementation based on a given runtime if it is generic enough so that it can help more people (even just as a snippet in the README !)

[Colmea]

Thanks for all these information.

Indeed I saw the section in the Readme but tbh it was not clear for me that the runtime validation was just provided "as-is", but not really used in the client.

I will look into the code to see if I can propose something in a PR !

Otherwise, maybe a small clarification in the Readme would be useful ? Especially on the "you can also generate a client with runtime validation" => "you can also generate runtime validation to be used with your client" ?

Anyway, thanks for your work on this and Panda !

Note: I saw openapi-zod but typed-openapi was more useful for us because we have both zod and io-ts in some legacy code

[Colmea]

Hey,

I came up with this, what do you think ?
So basically we find the zod schema from the endpoint, then parse the response.

The parse function will throws a ZodError if the validation does not pass.

Example with the GET request:

  // <ApiClient.get>
  async get(path: Path, ...params) {
    // Fetch data from the API
    const responseData = await this.fetcher(
      'get',
      this.baseUrl + path,
      params[0],
    );

    // Parse and validate the response data using the Zod schema
    const schema = EndpointByMethod.get[path].response;
    const parsedData = schema.parse(responseData);

    return parsedData;
  }
  // </ApiClient.get>

If it's good enough for you, I can create a PR.
To avoid any breaking change, I can also add a new flag in the CLI.

[astahmer]

I havent tried but this looks good !

thinking about it again I really want to avoid any maintenance regarding the runtime validation, so I think it would be best to have this as an example snippet in the README, along with this one

but I also understand that currently the way to create your own client is somewhat-clunky, adding a way to generate a custom implementation somewhere here using a callback that receives the current method, endpointByMethod (and anything else needed) would be future-proof for everyone's need

[andredewaard]

I think this line is a bit misleading if this isn't the case Or you can also generate a client with runtime validation using one of the following runtimes
but it doesn't validate at runtime, it just uses Zod to generate typescript types.
I understand you not wanting to maintain but why use Zod in the first place if we don't parse any at runtime?

[astahmer]

cause you can; you have the schema generated to do so; you can make your own abstraction on top of it

I understand your concern and my previous answer remains valid; if you can provide a good default then we can add it in the README

i'd also recommend looking for examples of other people using the library
https://github.com/search?type=code&q=saved%3A%22NOT+is%3Afork%22+typed-openapi&saved_searches=%5B%7B%22name%22%3A%22NOT+is%3Afork%22%2C%22query%22%3A%22NOT+is%3Afork%22%7D%5D&expanded_query=NOT+is%3Afork+typed-openapi