RPC Server Improvements
The RPC server stack (resto, src/lib_rpc_http
, src/lib_rpc
) suffers from several issues. This milestone collects several of them.
Problem: binary serialisation is eager and non-cooperative
Currently, binary serialisation is "all in one go", even for large values that have a significant lazy sequence of parts. (This is also known as the "baking rights problem" because the baking-rights RPC. This RPC gets information from the context in a lazy (by-need) manner, forces it all, serialises it, and sends it to the caller in one single write.)
Solution: There should be a combinator to express that some collection is lazy and there should be support for it in the serialiser. This is non-trivial because it requires modifications at multiple levels of the encoding stack. This milestone groups issues that, taken all together, addresses the problem above.
Note that this work requires changes to data-encoding and json-data-encoding too. As a result, this Milestone is somewhat strange w.r.t. organisation.
Associated issues on other repositories:
-
nomadic-labs/data-encoding#41 (closed) : add encoding combinator for Seq.t
-
nomadic-labs/json-data-encoding#9 (closed) : support new seq
combinator in Json backend -
nomadic-labs/data-encoding#42 : support chunked binary serialisation (preserving new combinator's laziness)
Problem: poor support for standard application-level formats
Server-sent events are a better format to send the streaming RPCs in. Using this standard (as opposed to our custom-made, ill-formed JSON stream) allows standard tools to cache, proxy, balance, etc. requests.
Problem: lack of stream-decoding
When decoding a value in JSON, there is no support for stream-deocding: we can only decode the whole thing in one go. This leads to some inefficient patterns in resto's underlying decoding functions.
Also note that whilst the binary backend of data-encoding supports stream-decoding, the functionality is not passed along to resto and so the same inefficient pattern is used too.