provide a rhai interface to the router service #3234
Conversation
There's a lot of very nasty unfinished code here, but some progress at least.
Make responses work Figure out how to handle errors in deferred responses Add json_parsing functions to existing json module
This comment has been minimized.
This comment has been minimized.
|
CI performance tests
|
These are minimal documentation changes to at least make it clear that it is possible to use `router_service` from rhai. We need much more documentation: - useful example (any suggestions?) - clearly document that router.request.body != supergraqph.request.body - clearly document other potential changes at router_service level...
Request and Response objects are different for router_service, so provide enough minimal documentation so that it's clear what is going on.
|
something that came up while working on #3569: I think we should work on the stream of |
Not sure what you mean, wouldn't those happen before the router_service? |
There was a problem hiding this comment.
Looks good overall, but we need a test with a defered query or a subscription to make sure the rhai APIs work as expected.
I don't see any multipart separator function in the rhai helpers so I doubt json_decoding will be used correctly in the router_response rhai service.
Not sure if this should be within the scope of this PR or done as a followup though.
| ServiceStep::Router(shared_service.clone()), | ||
| self.block.load().scope.clone(), | ||
| ) { | ||
| tracing::error!("service callback failed: {error}"); |
There was a problem hiding this comment.
Does this give a good error message? If not then maybe tell the user what they should do to to fix their code.
There was a problem hiding this comment.
that is the same message we use on the supergraph, execution and subgraph levels. It includes the error reported by rhai (like syntax errors, etc)
There was a problem hiding this comment.
@Geal this hasn't been addressed, do we have a followup issue?
There was a problem hiding this comment.
this does not need to be addressed in this issue, as it does the same thing as other rhai services. We can open an issue to look in more detail at rhai error handling though
Co-authored-by: Bryn Cooke <[email protected]>
Adds `Rhai` support for the `router_service`.
It is now possible to interact with requests and responses at the
`router_service` level from `Rhai`. The functionality is very similar to
that provided for interacting with existing services, for example
`supergraph_service`. For instance, you may map requests and responses
as follows:
```
fn router_service(service) {
const request_callback = Fn("process_request");
service.map_request(request_callback);
const response_callback = Fn("process_response");
service.map_response(response_callback);
}
```
The main difference from existing services is that the router_service is
dealing with HTTP Bodies, not well formatted GraphQL objects. This means
that the `Request.body` or `Response.body` is not a well structured
object that you may interact with, but is simply a String.
This makes it more complex to deal with Request and Response bodies with
the tradeoff being that a script author has more power and can perform
tasks which are just not possible within the confines of a well-formed
GraphQL object.
This simple example, simply logs the bodies:
```
// Generate a log for each request at this stage
fn process_request(request) {
print(`body: ${request.body}`);
}
// Generate a log for each response at this stage
fn process_response(response) {
print(`body: ${response.body}`);
}
```
Fixes #2278
---------
Co-authored-by: Geoffroy Couprie <[email protected]>
Co-authored-by: Bryn Cooke <[email protected]>
Adds
Rhaisupport for therouter_service.It is now possible to interact with requests and responses at the
router_servicelevel fromRhai. The functionality is very similar to that provided for interacting with existing services, for examplesupergraph_service. For instance, you may map requests and responses as follows:The main difference from existing services is that the router_service is dealing with HTTP Bodies, not well formatted GraphQL objects. This means that the
Request.bodyorResponse.bodyis not a well structured object that you may interact with, but is simply a String.This makes it more complex to deal with Request and Response bodies with the tradeoff being that a script author has more power and can perform tasks which are just not possible within the confines of a well-formed GraphQL object.
This simple example, simply logs the bodies:
Fixes #2278
Checklist
Complete the checklist (and note appropriate exceptions) before a final PR is raised.
Exceptions
Note any exceptions here
Notes
[^1]. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or ask for it to be labeled) as
manual test