Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make multiple endpoints more natural / intuitive #282

Open
1 task done
nemoDreamer opened this issue Mar 10, 2021 · 2 comments
Open
1 task done

Make multiple endpoints more natural / intuitive #282

nemoDreamer opened this issue Mar 10, 2021 · 2 comments

Comments

@nemoDreamer
Copy link

nemoDreamer commented Mar 10, 2021

If a RestLink defines multiple endpoints, it's safe to assume that each of these endpoints might want different headers, credentials, field-name normalization, response transformation, and even custom fetches.

The usual answer to requests for more per-endpoint options seems to be "use the root customFetch or a responseTransformer", but these seem overly verbose workarounds for simple cases such as headers or fieldNameNormalizer, especially given how common the use-cases are.

Additionally, splitting the logic for one endpoint across multiple callbacks defined in the parent makes maintaining multiple endpoints pretty messy. I think aggregating from various REST APIs is one of GraphQL's (and thus apollo-rest-links) main selling points.

Currently, only a per-endpoint responseTransformer, as well as an undocumented per-directive fieldNameDenormalizer, are supported, and the code to achieve these 2 different exceptions seems to have been architected in different ways.

A few folks have asked for different aspects of this larger issue, and the one-off fieldNameDenormalizer exception seems to have been a response to one of those? I feel there's an opportunity to solve this holistically, allowing for the same "get from directive or endPointOptions or link default" logic when determining the final source of the following:

  • responseTransformer
  • fieldNameNormalizer
  • fieldNameDenormalizer
  • headers
  • credentials
  • customFetch

At the least, a per-endpoint customFetch would clean up the spread-out nature of working with multiple endpoints by allowing for cleaner exceptions / workarounds.

❤️

Related issues:

Issue labels

  • feature
@fbartho
Copy link
Collaborator

fbartho commented Dec 1, 2021

This definitely feels like a worthwhile project if somebody wants to tackle this

@patryk-smc
Copy link

This would be wonderful. We are currently looking into supporting multiple REST services, and it doesn't seem to be fun. I wish that Apollo team would be more involved in this package!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants