astahmer / typed-openapi

Generate a headless Typescript API client from an OpenAPI spec
https://typed-openapi-web.vercel.app/
200 stars 23 forks source link

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

Open Colmea opened 8 months ago

Colmea commented 8 months ago

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 commented 8 months ago

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

image

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 https://github.com/astahmer/typed-openapi/issues/19#issuecomment-1932182486 see prev discussions on the topic https://github.com/astahmer/typed-openapi/issues/18#issuecomment-1833322629 https://github.com/astahmer/typed-openapi/issues/3#issuecomment-1695647149

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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