Replies: 2 comments
-
|
Potentially related github issues: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@red-0ne Friendly reminder to please review/update this when you have a chance! (non-urgent) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
After refactoring our
RelayRequest/Responsepayload to be just bytes slices light was shed to an interesting categorization of the relays work-flow wise.This raises very pertinent questions regarding how we categorize our services.
Except the need to know the RPC type for:
Accounting: Know the methods of the JSON-RPC calls and HTTP headers and paths for REST...
Internal error replies: e.g. We reply from our internal errors with a 500 status code in the header for HTTP, stick an Id to a JSON-RPC reply for this one...
But workflow-wise we could categorize them into:
Symmetric protocols: To each request corresponds a reply (1-1). These almost exclusively rely on TCP/HTTP transport (? At least we'll be sticking to it for a some time). This could include JSON-RPC, REST and gRPC
Asymmetric protocols: Where we could have many replies for a single request (e.g. subscriptions) or many requests for a single reply (e.g. chunked file uploads) these are n-m req/res protocols. They may transport over TCP (messaging web apps...) or UDP/WebRTC (video streaming, gaming, etc...). This could include Websocket, gRPC and JSON-RPC
If we adhere to just passing the bytes of the original request, it doesn't matter which RPC type it is but knowing if we're gonna handle stateful or stateless communication matters a lot and will dictate which part of the code is going to handle that request.
Our current jsonrpc.go servers could support all the symmetric protocols with very low effort and both the appgateserver and the relayerproxy could be agnostic of the RPC type as long as its symmetric.
We could then implement the asymmetric ones (starting with Websockets then gRPC) but it would be the same logic/flow handling them IMO.
We could couple that to partial decoders given the RPC type is known (regardless of its flow) to extract the relevant info. for accounting and error handling.
WDYT?I think this raises very pertinent questions regarding how we categorize our services.
Except the need to know the RPC type for:
Accounting: Know the methods of the JSON-RPC calls and HTTP headers and paths for REST...
Internal error replies: e.g. We reply from our internal errors with a 500 status code in the header for HTTP, stick an Id to a JSON-RPC reply for this one...
But workflow-wise we could categorize them into:
Symmetric protocols: To each request corresponds a reply (1-1). These almost exclusively rely on TCP/HTTP transport (? At least we'll be sticking to it for a some time). This could include JSON-RPC, REST and gRPC
Asymmetric protocols: Where we could have many replies for a single request (e.g. subscriptions) or many requests for a single reply (e.g. chunked file uploads) these are n-m req/res protocols. They may transport over TCP (messaging web apps...) or UDP/WebRTC (video streaming, gaming, etc...). This could include Websocket, gRPC and JSON-RPC
If we adhere to just passing the bytes of the original request, it doesn't matter which RPC type it is but knowing if we're gonna handle stateful or stateless communication matters a lot and will dictate which part of the code is going to handle that request.
Our current jsonrpc.go servers could support all the symmetric protocols with very low effort and both the appgateserver and the relayerproxy could be agnostic of the RPC type as long as its symmetric.
We could then implement the asymmetric ones (starting with Websockets then gRPC) but it would be the same logic/flow handling them IMO.
We could couple that to partial decoders given the RPC type is known (regardless of its flow) to extract the relevant info. for accounting and error handling.
WDYT?
Beta Was this translation helpful? Give feedback.
All reactions