Feature Proposal - RestLink chains

[willyboy]

Chainable Rest Links

Background

The current architecture of the Rest Link poorly supports hitting multiple public APIs from our queries. Different APIs have different headers, different response formats and types, different credentialing mechanisms, and more.

There are many workarounds presented by a number of issues:
#264
#190

These are good one off solutions but aren't scalable patterns.

Take for instance an architecture where each feature is responsible for owning the setup for the backends it is going to use. This allows the feature to be used anywhere with no extra setup (a black box). It needs to be able to register the endpoints it is going to consume. Unfortunately, without composable rest links, to do this is hacky at best.

Proposal

Allow multiple RestLinks to be defined so that when you have situations like different headers for different endpoints, you can just add another RestLink to the chain. While maybe not a perfect solution for the problem (a perfect solution by be allowing everything for any call to be configurable from the directive), it's a healthy backstop that requires minimal effort to implement.

Implementation

Instead of deleting all @rest directives from a query in the RestLink, only delete the ones which have matching endpoints. If there is another RestLink in the chain (I think we can check the previous and next links? If not, we may have to have a toggle for saying we want composability). If a directive doesn't have a matching endpoint in one RestLink, we'll assume it's specified in the next. If we get to the end of the chain with no matches, then throw an error.

We also need to share data across the context so that as the query is processed, all data is available and we need to update the cache key for the query so that it incorporates the correct directives. I have a patch-package diff that handles all of this if the maintainers feel like this is a good enhancement.

[fbartho]

hey @willyboy! I’m definitely interested in seeing this approach. Conceptually I don’t have an objection to this approach. Particularly if it has a minimum of configuration options and/or doesn’t require much change to the @rest( graphql annotation.

Feel free to submit a PR and I’ll take a look!