Comments (4)
My understanding of initial use cases is:
- As a router operator, I want to expose the
header1
HTTP Response header returned fromsubgraphB
to the requesting client as an HTTP Response header. - As a router operator, I want to expose the
header1
HTTP Response header from any subgraph to the requesting client as an HTTP Response header. - As a router operator, I want to expose the
header1
from all subgraphs to the requesting client as multiple HTTP Response headers (i.e., repeated) — e.g., consider headers likeset-cookie
. - As a router operator, I want to reduce and expose the
header1
HTTP Response header returned from any subgraphs to the client as a single HTTP Response header — e.g., like aSurrogate-Key
header.
However, I (we?) don’t currently/yet have clarity into what the expectations are for subgraphs that are touched multiple times in a query plan’s execution (i.e., there are multiple FetchNode
s to the same subgraph). For example, if subgraphB
is called first, then called in a subsequent (tertiary+?) _entities
fetch, but each returns a header1
HTTP Response header, when is this permitted? (Always?) What is the behavior? (First wins? Last wins?) The answer for the Surrogate-Key
scenario seems more intuitive to me, while the others are perhaps a bit more blurry in my mind right now.
from router.
As a follow-up to the initial version, doing this declarative in the graph is appealing, but this could be a follow-up issue. Those scenarios are very similar, but the stories user perspective changes slightly:
- As a subgraph operator, I want to ask to expose the
header1
HTTP Response header that I will return from my subgraph to the requesting client as an HTTP Response header. - As a subgraph operator, I want my header to be interpolated with other
header1
HTTP Response headers returned from other subgraphs to the client as a single response header — e.g., participating in aSurrogate-Key
HTTP Response header scheme.
One could imagine that these could be done with core-directives in the subgraph. However, I'll note that there are governance needs here to cover a router operator's concern that arises in these scenarios, but that I'd claim that those governance concerns can be handled supergraph composer/processor rules. I'd claim that those are outside of the scope of the Router's concern, but might be:
- As a router operator, when subgraph operators are requesting to return HTTP headers to the client, I want to be able to control what can be returned.
from router.
Closed as part of #303. This should be possible now with the new header extension configuration stuff which is incoming!
from router.
You should add this in the documentation... there's only information on inbound header propagation.
from router.
Related Issues (20)
- docs: broken link for "tech notes" HOT 3
- Rust v1.78.0 router-bridge startup panic HOT 1
- trace_id check to accepts dashes as UUID format HOT 6
- distributed Query Plan cache may be poisoned by experimental query plan features HOT 2
- Proposal: Remove apollo-router-scaffold
- Add test that limits max size of router json schema
- Native plugins not called on invalid GraphQL query since 1.45
- `early_cancel` is not documented HOT 1
- document private response caching
- Request/Response body size metric per operation name
- Rhai Scripting - how to get subgraph response code HOT 1
- Query plan cache key follow up
- High increase of base memory usage by Router v1.46.0 HOT 1
- Subgraph batching clears the context when responding with an array of the same operation HOT 1
- Graphql requests return non-graphql responses
- Add support for studio trace id selector in telemetry HOT 1
- Metrics overflow should be logged as a warning rather than error
- Support unix time in ms in rhai scripts
- Hot reload downtime under load
- Add standard attributes to all logs from context keys
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from router.