RESTDataSource, need custom context per Request/Response

[jounii]

I'm currently refactoring some REST API to use RESTDataSource as the fetch implementation. Current implementation uses similar custom rest/fetch implementation, which is fairly okay but does have it's caveats and does not provide the caching features.

However it does provide way to pass custom context on request/response pair. This is used for (in RESTDataSource terms) the parseBody to do more detailed json data denormalization. I was hoping I could implement this just extending the RESTDataSource, but seems it's not that easy as the request/response pair is being detached from each other. The didReceiveResponse does link up a bit, but as how the node-fetch Request and Response are internally initialized, any custom additions to the init: RequestInit parameter are not passed through just with Request and Response objects.

Right now I see only three options for this.

1. FEATURE REQUEST: RESTDataSource should have way to pass "request context" which is passed through the pipe down to parseBody. This would work then when extending from RESTDataSource
2. Hackly solution I'm trying is to use local Map to store the data and link by "request-id" which is passed through the request headers and then copied in didReceiveResponse to response headers which can be accessed in parseBody.
3. Don't try to extend RESTDataSource, just create wrapper class and use RESTDataSource as it-is for any fetches, post process the responses result data in the wrapper

Because lack of direct support for option 1, I'm a bit leaning towards the option 3, although the RESTDataSource code seems to be done extending in mind. So probably have to extend RESTDataSource for some customzation and then wrap it..

Other suggestions?

[glasser]

The feature request seems reasonable. Perhaps the best approach here would be a GraphQL-style extensions that you can put on the RequestOptions object which you're welcome to do whatever you want with. I don't plan to implement this myself now but we'd be happy to review a PR.