Add ADR for passthrough rpc #352
Conversation
| ### Correlation of Requests and Response from the passthrough provider | ||
|
|
||
| Since the jsonrpc id is also passed-through, how does Ripple know which id space the response is from? | ||
| For example, if app1 makes a "methodA" call with jsonrpc id=1 and app2 makes a "methodB" call also with jsonrpc id=1 and both are sent through the passthrough. When the response comes back with id=1, how does Ripple know the response is meant for app1 or app2. |
There was a problem hiding this comment.
Can we preload a correlationId similar to the provider broker into the __ctx. Correlation Id can map back to the connection id for the rpc router to send that back depending on the transport
| For example, if app1 makes a "methodA" call with jsonrpc id=1 and app2 makes a "methodB" call also with jsonrpc id=1 and both are sent through the passthrough. When the response comes back with id=1, how does Ripple know the response is meant for app1 or app2. | |
| "__ctx": { | |
| "correlationId": uuid-uuid-uuid | |
| "appId": "test.firecert" | |
| } |
| Support config for Ripple in the device manifest file | ||
|
|
||
| ``` | ||
| { |
There was a problem hiding this comment.
Feel we can reuse the connections and endpoints to suppport for multiple proxied rpc methods
| { | |
| { | |
| "endpoints": { | |
| "thunder" : { | |
| "url": "ws://127.0.01:9992/jsonrpc", | |
| "protocol": "websocket" | |
| } | |
| } |
| "passthrough_rpcs": [ | ||
| { | ||
| "method": "device.model", | ||
| "url": "ws://127.0.0.1:9992/jsonrpc", |
There was a problem hiding this comment.
Schema can support either a url or a named enpoint as the above suggestion
| If the message of the rpc method call is just a passthrough, should Ripple still do the argument validation? | ||
|
|
||
| #### Option 1: Ripple does the validation | ||
| Ripple can continue to do the validation, however currently the validation is done by the RPC handler when it deserialized the message into Rust structs. Passthrough providers should not reach Ripple handler code, and thus should not be deserialized. |
There was a problem hiding this comment.
Feel this should be part of the contract tests for the pass-through handler having Ripple doing the validation adds additional processing probably takes away some of the latency benefits expected from the passthrough operation.
|
|
||
| #### Option 2: The provider does the validation | ||
| The provider already will need to deserialize the message, and thus can do the validation there. For example, if the spec says a field is a string but the client passed a boolean, it should fail to deserialize on the provider. | ||
| Down side is that the provider now need to implement all the boiler plate errors in the same way that is expected for any firebolt APIs. Each provider may implement it differently and not to spec. |
There was a problem hiding this comment.
Given Ripple still handles the checks for capabilities and grants error template will be reduced to the individual handler errors which probably needs definition as well in the open rpc.
|
|
What
What does this PR add or remove?
Why
Why are these changes needed?
How
How do these changes achieve the goal?
Test
How has this been tested? How can a reviewer test it?
Checklist