Instantiate services with config

[clragon]

First off, lovely package, thank you for making this.

Description
It would be nice to locally configure the OpenAPIConfig of a given API call when making it.

Problem it Solves
In some cases, when writing more complex applications,
it is important for me to be able to change the configuration of a given specific call.

Proposed Solution
I would like to be able to pass an OpenAPIConfig to any request, optionally,
defaulting to the global configuration for any property not specified.

Alternatives Considered
I can alter the global config right when I need to, but this is messy and might lead to complications.

It would also be an idea to be able to instantiate a Service or all Services with a given Config, so that they can be used pre-configured and distributed non-globally, e.g. with a React Context.

Additional Context
It is possible that a generation option for this exists and I just didnt see it anywhere.

[mrlubos]

Hi @clragon, thank you for opening an issue! Do interceptors not achieve what you're after? If not, can you share your configuration, and perhaps go more into specifics of what are you trying to achieve?

[clragon]

Hi @mrlubos, thanks for your reply.

In my specific case, I am writing an End To End test against my backend.
Because of that, I have to act as multiple users at once, so credentials are swapped out often.

Interceptors are great, but they are not the kind of scope I am looking for. An interceptor cannot identify that I wish for e.g. this specific request right now the be authenticated with different credentials than normally.

I am looking more for something like this:

// OpenAPIConfig could be optional last argument?
MyService.someRequest({
  TOKEN: someSpecificToken,
});

or maybe like this:

// OpenAPIConfig could be optional argument
const specificUserService = MyService({
  TOKEN: someSpecificToken,
});

specificUserService.someRequest();

which is somewhat more involved, but could be cleaner as a user interface, as it does not "pollute" method parameters.

Does that track?

[mrlubos]

Yep. I like the direction of the latter approach, but will need to give it more thought before implementing. Is this a high priority issue for you? What were you doing prior to using openapi-ts if you're migrating?

[clragon]

I have been looking for a simple openapi generator for a while, so finding this package, I think of myself very lucky!
I am basically starting a new project right now and picking a generator, since my past choices werent necessarily ideal.

The large openapi generator generates a whole "sub-package" which is too much for what I usually want to achieve, and I like to avoid monorepos.

I have also previously tried more opinionated packages like rapini and also @openapi-codegen/cli, which both have different approaches to passing per-request configurations - the former, as last argument, which is extremely tedious with many paramaters, the latter, as one big config object that is quite nested.

Those packages also provide react query hooks, which I fancy, but in my current project, they are not needed.
Overall, I wouldnt consider this immensly high priority, but it would make my workflow quite a bit nicer, for sure.

[mrlubos]

Those are some kind words @clragon, thank you! I'm not seeing in your list of alternatives openapi-typescript which is the most popular one. What's your opinion on it?

Separately, we have something coming up for TanStack Query later this year 👀

[clragon]

openapi-typescript does seem very interesting, I havent seen an approach like this before.

personally, I think if I am using a generator, which is already somewhat of a committment, I'll take the full treatment of also generating axios, etc, because it makes my life easier.
so, openapi-typescript seems a bit bare bones for my taste. I could see it being useful at my workplace though, where less code generation is preferred because we commonly have specific requirements for how we want to structure our code.

[mrlubos]

Do you mind chatting more about it? We strive to be a superset of openapi-typescript in terms of features. When you say less generated code is preferred, what exactly are you referring to? Are you aware that you can choose which parts of the generated output you need? For example, skip creating services, schemas, etc.?

[clragon]

right! code generation for me is a bit of a black and white situation.
When I can, I prefer not to, since it introduces extra utilities which need to be maintained and understood by the project members.
But when code generation has large benefits, I prefer it to be extensive so that I can get maximum usage out of it.

In a sense, code generation has to be justified in my eyes.
Because of that, personally I prefer code generation that gives me more rather than less.
e.g. generating all my models, my api calls and my hooks all at once,
instead of just generating my models.

But, for example, the overhead of making my API client a package on its own exceeds the scope of most of my projects.

[mrlubos]

Got it @clragon. We want Hey API to be your tool of choice for working with API data, no matter the project size. If you work with APIs, you work with Hey API. The idea is you could add or remove features as necessary as the scope changes. If you think of anything that could achieve this objective in your eyes, please let me know. We're just getting started with this thing!

[mrlubos]

@clragon I updated the issue title, let me know if that doesn't fully capture the solution you're after