Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Colmea opened this issue Mar 6, 2024 · 4 comments

Comments

@Colmea
Copy link

Colmea commented Mar 6, 2024

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
Copy link
Owner

astahmer commented Mar 6, 2024

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 #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
Copy link
Author

Colmea commented Mar 6, 2024

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
Copy link
Author

Colmea commented Mar 7, 2024

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
Copy link
Owner

astahmer commented Mar 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants