Open smyrick opened 6 months ago
Maybe:
coprocessor:
url: http://127.0.0.1:8081
supergraph:
response:
body: # if this is provided as an object, then sub-fields are false by default, eg data
errors: true
extensions: true
Note that we are also interested in this for subgraph response.
One question would be to define what body
in the coprocessor response means. I believe right now if you send back a body
field it will fully overwrite the body. What would the expected semantics of sending back {body: {errors: [...]}}
be with the config above: would the idea be that since you didn't ask for data, the lack of mentioning data means you want to leave it alone? Or should it mean to remove it? Is the answer perhaps different between a continue
and a break
?
I would assume you would only mutate what was sent to the coprocessor. If you wanted to change the data
you should have to send the data
, but this also maybe would require more conditional logic? Like maybe I only want to change the data if there was an error.
Actually then maybe the break
could be used so you only send errors
to the CP but the CP can respond with the full new response on break
Yeah, the semantics are a bit funky too because body
in a coproc means something different for continue vs break: for continue
it means "overwrite the body
of whatever I'm processing (which might be a request or a response)" whereas for break
it means "use this as the body for a response to send back now"...
Is your feature request related to a problem? Please describe.**
Today I can configure the Router to send the response, which might have
data
orerrors
orextensions
, to the coprocessor so that it can perform extra logic. However I can only choose to send the whole responsebody
. If I am returning data back this body may be quite large and can cause performance issues or even errors inside my coprocessor trying to process large responses.Instead I would like the ability to decide what parts of the GraphQL response I would like sent to a coprocessor.
Config today
Describe the solution you'd like**
I would like the ability to decide what parts of the GraphQL response I would like sent to a coprocessor, so I can reduce the payload size.
It probably makes sense for this to be at the
SupergraphResponse
phase since that is where the Request is also in a parsed state vs theRouterResponse
should be reserved for changing the entire response as it is about to be sent via HTTP back to the clientPossible new config:
Describe alternatives you've considered**
I could use Rhai scripts to process particular parts of the response
Additional context
Actually having a large payload can cause the coprocessor to fail which is a separate issue, so this feature request is one way in which we can solve that