github.com/number571/tendermint@v0.34.11-gost/docs/architecture/adr-057-RPC.md (about)

     1  # ADR 057: RPC
     2  
     3  ## Changelog
     4  
     5  - 19-05-2020: created
     6  
     7  ## Context
     8  
     9  Currently the RPC layer of Tendermint is using a variant of the JSON-RPC protocol. This ADR is meant to serve as a pro/con list for possible alternatives and JSON-RPC.
    10  
    11  There are currently two options being discussed: gRPC & JSON-RPC.
    12  
    13  ### JSON-RPC
    14  
    15  JSON-RPC is a JSON-based RPC protocol. Tendermint has implemented its own variant of JSON-RPC which is not compatible with the [JSON-RPC 2.0 specification](https://www.jsonrpc.org/specification).
    16  
    17  **Pros:**
    18  
    19  - Easy to use & implement (by default)
    20  - Well-known and well-understood by users and integrators
    21  - Integrates reasonably well with web infrastructure (proxies, API gateways, service meshes, caches, etc)
    22  - human readable encoding (by default)
    23  
    24  **Cons:**
    25  
    26  - No schema support
    27  - RPC clients must be hand-written
    28  - Streaming not built into protocol
    29  - Underspecified types (e.g. numbers and timestamps)
    30  - Tendermint has its own implementation (not standards compliant, maintenance overhead)
    31    - High maintenance cost associated to this
    32  - Stdlib `jsonrpc` package only supports JSON-RPC 1.0, no dominant package for JSON-RPC 2.0
    33  - Tooling around documentation/specification (e.g. Swagger) could be better
    34  - JSON data is larger (offset by HTTP compression)
    35  - Serializing is slow ([~100% marshal, ~400% unmarshal](https://github.com/alecthomas/go_serialization_benchmarks)); insignificant in absolute terms
    36  - Specification was last updated in 2013 and is way behind Swagger/OpenAPI
    37  
    38  ### gRPC + gRPC-gateway (REST + Swagger)
    39  
    40  gRPC is a high performant RPC framework. It has been battle tested by a large number of users and is heavily relied on and maintained by countless large corporations.
    41  
    42  **Pros:**
    43  
    44  - Efficient data retrieval for users, lite clients and other protocols
    45  - Easily implemented in supported languages (Go, Dart, JS, TS, rust, Elixir, Haskell, ...)
    46  - Defined schema with richer type system (Protocol Buffers)
    47  - Can use common schemas and types across all protocols and data stores (RPC, ABCI, blocks, etc)
    48  - Established conventions for forwards- and backwards-compatibility
    49  - Bi-directional streaming
    50  - Servers and clients are be autogenerated in many languages (e.g. Tendermint-rs)
    51  - Auto-generated swagger documentation for REST API
    52  - Backwards and forwards compatibility guarantees enforced at the protocol level.
    53  - Can be used with different codecs (JSON, CBOR, ...)
    54  
    55  **Cons:**
    56  
    57  - Complex system involving cross-language schemas, code generation, and custom protocols
    58  - Type system does not always map cleanly to native language type system; integration woes
    59  - Many common types require Protobuf plugins (e.g. timestamps and duration)
    60  - Generated code may be non-idiomatic and hard to use
    61  - Migration will be disruptive and laborious
    62  
    63  ## Decision
    64  
    65  > This section explains all of the details of the proposed solution, including implementation details.
    66  > It should also describe affects / corollary items that may need to be changed as a part of this.
    67  > If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
    68  > (e.g. the optimal split of things to do between separate PR's)
    69  
    70  ## Status
    71  
    72  > A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
    73  
    74  {Deprecated|Proposed|Accepted}
    75  
    76  ## Consequences
    77  
    78  > This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
    79  
    80  ### Positive
    81  
    82  ### Negative
    83  
    84  ### Neutral
    85  
    86  ## References
    87  
    88  > Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
    89  
    90  - {reference link}