Proxy headers from Subgraphs to client

[vasily-polonsky]

Component(s)

No response

Is your feature request related to a problem? Please describe.

I want to pass headers from subgraph back to client, but only found a way to pass from router to subgraph. Would be cool to have this in proxy settings as well. Found a way to create a custom module to modify headers using custom modules. Would be nice to have this feature as it is much easier, you don't have to build a router and you need only configure yaml file.

Describe the solution you'd like

headers:
  all: (subgraphs)
    response:

Describe alternatives you've considered

No response

Additional context

No response

[github-actions[bot]]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible. The roadmap is driven by our customers and we have to prioritize issues that are important to them. You can influence the priority by becoming a customer. Please contact us here.

[StarpTech]

Hi @vasily-polonsky, thank you for sharing your experience with us. I like the proposal. It's not on the Roadmap yet but will discuss it internally. How was the experience to build a custom module?

Do you reach out as a company or individual? Thank you.

[jensneuse]

If 2 subgraphs return the same Header which should be "backwarded", and they return different values, what should be the desired behavior? Last write wins? As in, last returned value from a subgraph gets returned?

[vasily-polonsky]

Hi @StarpTech I reach out as an individual. I have only had positive experiences, thanks to examples and documents.

[vasily-polonsky]

Hi @jensneuse I think the best way is to follow the same approach as its already done for proxying request header https://cosmo-docs.wundergraph.com/router/proxy-capabilities In case the user has multiple subgraphs that return the same header, he can solve this problem by specifying a concrete graph.

headers:
  all: # Header rules for all subgraph requests.
    response:
      - op: "propagate" 
        named: X-Test-Header 
       
  subgraphs:
    specific-subgraph: # Will only affect this subgraph
      response:  
        - op: "propagate"
          named: Specific-Header

In my case, I only need to propagate the header from a specific subgraph to the client.

[StarpTech]

Hi @vasily-polonsky, this is definitely something we want to add in the future but it has no priority right now.

[lancethomas1]

@StarpTech this seems pretty bad. For us, it's making our http edge cache useless. On our subgraphs, we pass cache-control maxAge values on certain fields through schema directives price: [Price] @cacheControl(maxAge : 300, scope : PUBLIC)

In our non-federated current environment, this data is sent to our edge cache through the cache-control response header so the edge cache knows to set the TTL for that query to 300 because it was a query for price. And if we don't declare in the schema a maxAge then the subgraph sends cache-control:no-cache (like we need to do for our cart subgraph).

But what we are encountering here is the cosmo router is dropping all response headers from the subgraph which means our edge cache is using a default TTL on all unique queries. This is problematic when UI queries for a users cart, then adds an item to the cart then makes the same cartById query again but is served a cached cart response which does not have the item the use just added to the cart.

In our lower environments, we have remove the default TTL config in our edge cache but we can't go to prod without an edge cache.

Just wanted to add some context/examples of our experience with this issue.

[lancethomas1]

@StarpTech do you have a comparable solution like this? https://www.apollographql.com/docs/federation/performance/caching/

[jensneuse]

We're currently working on implementing a solution for both use cases in #1155

[vasily-polonsky]

@jensneuse @StarpTech Thank you so much for delivering this Feature Request. Works great, no need to use custom modules now, which means upgrading the router version will be even easier.