Feature request : provide custom Request module when generate resolver

[moyara]

Hello, I have a feature request for custom request.
I see resolver_builder uses built in request module.
https://github.com/IBM/openapi-to-graphql/blob/master/packages/openapi-to-graphql/src/resolver_builder.ts#L15

It will be useful to provide custom request module such as custom-configured request or 3rd party packages like https://www.npmjs.com/package/retry-request

[Alan-Cha]

@moyara I think it is possible to do this using the customResolvers option. Let me know if you think otherwise.

[moyara]

@moyara I think it is possible to do this using the customResolvers option. Let me know if you think otherwise.

But then I have to write All resolvers to apply custom request per each endpoint. I am lookinf for more general way to solve this without maintaining like 100 apis.

[Alan-Cha]

@moyara I think currently we are not looking to support a number of different request modules. However, if retry-request has a similar API as request then we can consider adding it in, but this whole situation raises a number of questions concerning where does this decision lead to. @ErikWittern could you also weigh in?

[ErikWittern]

For some larger context, OtG currently depends on the request module for invoking the REST API, which was a common option when we started the project. Since then, that module has actually been put into maintenance mode only. So it may generally be a good thing to reconsider whether to use another option, ideally promise-based to allow for the convenient use of async ... await.

The specific question raised by this issue is whether users should be allowed to provide their own library instead of whichever one OtG depends on. I see two options to make that happen:

1. Providing a custom library is allowed, so long as it has the same API as the one used by OtG. E.g., replacing request by request-retry may easily be possible because they share (mostly) the same API (maybe this would be on the user's own risk of proper functionality).
2. OtG would need to provide an abstraction that allows to easily integrate any HTTP library, no matter what API it hast.

IMO, option 2 likely opens up a bunch of challenges and I see other issues more pressing at this point. Option one sounds more feasible to me, but: I would definitely not want to impede in any way with the ease-of-use OtG currently offers. I.e., removing request as a dependency and forcing users to provide it as a peer-dependency may introduce an additional step in getting started, which I want to avoid. Thus, the challenge to make this happen to me is allowing to provide a custom HTTP library without any impact on the easy way in which OtG can currently be used.

[wtrocki]

Since cost of the bundle size for Node.js does not matter that much it will be possible to use default request-like api and then allow to override it.

Currently in node and browser ecosystem fetch api seems to be standard way to do things. So using fetch or request like wrapper with default implementation provided in library will be a game changer and have no drawbacks from usability and unlimited customization options

This will allow various customisations like auth using cert pinning etc.

Edit:
Quick google search shows that there are more than 40 libraries on NPM that will work with fetch like API, however request seems to be still more popular
https://www.npmtrends.com/node-fetch-vs-request