Reuse RouteConfig in consuming application

[johanndev]

Hi!

First, thanks for this awesome library! :)

Is there any way to leverage the route configuration in the creation of http clients? My goal is to define the route only once (in the route config) and somehow generate client code that for example uses the fetch API to issue requests against a backend and validates the responses against the configured ZodSchema.

As it stands today, I have to manually create my http client classes in TS and repeat the information that I have already provided in the route config.

I guess what I'd like to have is something similar to creating TS clients from a OpenAPI spec.

How do you usually handle the creation of http client classes?

[AGalabov]

Heelo @johanndev thank you for the kind words. I can share some of the thoughts we've had about the library. Yes we had the idea of going one step further by creating a "framework" for TS client-server integration. However that also comes with some restrictions of integration. So we went for a more generic approach with the zod-to-opeanpi library - i.e it only handles the generation of OpenAPI from zod schemas.

However in a project of ours we have something that looks pretty much like this:

// This is an express router abstraction
router.post('/addresses', {
    handler: createAddress, // some handler function/class method
    route: createAddressRoute, // a route following the route config format/schema.
});

and client side we have a code that dos:

// This generic type would enforce Typescript check for the provided body (data) and query params
this.request<typeof createAddressRoute>(
  {
    method: 'POST',
    url: '/user/addresses',
    data,
  }
)

Overall we do not intend on making this a part of @asteasolutions/zod-to-openapi. Interestingly you are the second person that asks something in that direction. So we might consider creating another library with that abstraction.

Let me know if you have further thoughts around this topic or if I can help with something specific.

[johanndev]

I for one are very much in favor of such a library - it would be very helpful for a lot of our projects :)

Let me know if you have further thoughts around this topic or if I can help with something specific.

I also started experimenting with a method ála your request<T> example.
Would you consider sharing your implementation? I'm especially curious how you handle the checks of the query params.

[AGalabov]

I for one are very much in favor of such a library - it would be very helpful for a lot of our projects :)

I am glad to heat that. We'd consider internally if and when the required effort could be made.

And as for

Would you consider sharing your implementation?

I would not be able to help. The example I gave you is a subset of the current implementation we have in place for a project that is not open source and I cannot share it. The only way we would be able to share some of it is if/when we make the effort to create something more generic that we can extract in a library of its own.

However for the query parameters on the client side request<T> method it is a very straight forward usage of generic in Typescript so I think I can help you with a pointer for that.

export type QueryOf<R extends RouteConfig> = R['request'] extends {
  params: z.ZodType<unknown>;
}
  ? z.infer<R['request']['params']>
  : never;

interface RequestConfig<R extends RouteConfig> {
  params?: QueryOf<R>;
}

and all you need to do is to make the request method take a generic that extends RouteConfig and its parameters follow the RequestConfig object structure. Hope that helps.