How to dynamically assign schema to openapi-fetch request?

[licongy]

I am trying to use Remix + react-query + oepnapi-fetch to build a server-side api proxy for request processing. That is, after validating the schema info on the client side, sending path/body/params to the api proxy, adding authentication/middleware, and then making the request on the server side.

The purpose of this approach is to prevent token exposure in client-side js (even with short-lived access token), centralise log management, and handle other proxy things (if any).

However, openapi-fetch's schema checking occurs at the compiler time, which restricts runtime dynamic assignments. Although I can bypass the type-checking of PathsWithMethod by using assertions, it's hard to bypass MaybeOptionalInit, and doing so defeats the purpose of the existing beautiful design. So, I wonder if there is a way to leverage both openapi-fetch and API proxy effectively? Thanks so much!

[drwpow-figma]

This is probably a hiccup with any typed client, not just openapi-fetch, because it sounds like you might need different types for the client vs the server (or the proxy; whichever layer differs I’m not entirely sure). If that’s the case, the simplest recommendation is if the shapes are different, then those are 2 different OpenAPI shapes. Perhaps they don’t have to be separate schemas, but even if they reuse the same methods+statuses but handle different shapes, you can always split your OpenAPI schema into 3 documents: client paths, server paths, and shared components. That way you can reuse most of the same schema but just describe the ways in which they may depart.

If your OpenAPI schema accurately describes all shapes properly, openapi-fetch can keep up (as can any manually-typed things using openapi-typescript). And if you’re dealing with client and server, those have to be initialized twice anyway. But also know that initializing multiple openapi-fetch instances cost nothing—they basically only save a couple options and keep type inference but are so lightweight and performant to spin up you can have as many as you need.

Lastly, this probably goes without saying, but whenever you deal with “untrusted” shapes (e.g. serverside, validating clientside—clientside can never truly be trusted), those can always be unknown and you can throw out typing temporarily. Types are only for trusted, validated shapes (which IMO the client can always assume server responses are trusted and typed correctly).