You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
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 aresponseTransformer
", but these seem overly verbose workarounds for simple cases such asheaders
orfieldNameNormalizer
, 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-link
s) main selling points.Currently, only a per-endpoint
responseTransformer
, as well as an undocumented per-directivefieldNameDenormalizer
, 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 orendPointOptions
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:
headers
per endpoint #190@rest
directive #215Issue labels
The text was updated successfully, but these errors were encountered: