Soroban RPC: Is JSONRPC necessary?

[rustic rover]

We (the platform team) recently started the productization of soroban-rpc, encountering some problems in the glue layer between HTTP and JSON RPC, for which we created an upstream ticket https://github.com/creachadair/jrpc2/issues/99

The upstream maintainer brought the point of JSONRPC not being very useful when used in conjunction with HTTP https://github.com/creachadair/jrpc2/issues/99#issuecomment-1508930995:

In general, there's not much reason to use JSON-RPC in an environment where you already have access to make HTTP or HTTPS requests. JSON-RPC doesn't have any standard notion of request metadata, for example, and inside an HTTP request the version tag, request ID, etc., are redundant when you have headers. A Bridge allows HTTP to act as a transport, but an API that needs the full expressive power of HTTP should probably use that instead of JS

I must admit I agree. I am not familiar with the original reason to use JSONRPC but, as I see it, it doesn't really give us much over plain HTTP+POST+JSON.

It does give us a standard error format, but I don't think it provides much more than that.

What are your thoughts?

[night siren]

One of the reasons we chose json-rpc is because it's transport agnostic. This opens the door for alternative transports either implemented in soroban-rpc or other applications. For example geth (the main ethereum client) has IPC as an optional transport, which is used heavily in backend-to-backend comms. Another example is that dapps communicate with metamask using the same json-rpc interface

[dense hamlet]

Iirc that ☝🏻 was the only reason we went with it. Was there other reasons?

[dense hamlet]

Is it correct that Infra hosts will only use HTTP and IPC is mainly useful for running nodes on your local machine?

[hybrid rampart]

Are those backend scenarios where you need better streaming/push support that maybe don't work as well over HTTP? That being said, I thought this was a solved problem over HTTP 2?

[near zephyr]

Original reasons (pulled from a comment thread in confluence somewhere) were mainly:

• It's what everyone else in the blockchain space does. Probably not the place that's worth spending a ton of effort innovating.
• Easy to add support for streaming/push/etc over websocket (or other transport) (There's a thread somewhere comparing approaches and browser support for this)
• Minor: Request batching

The main drawback is lack of access to REST api tooling:

• openapi (There's openRPC, but it's not widely supported)
• advanced ALB path-routing, and varnish/nginx/etc proxy support generally
• Not "browser-accessible". Can't browse the data in your browser.

[near zephyr]

That said, with hindsight, I think REST may have been a better choice. But not sure it is worth the effort and disruption of changing it now.

[supple quail]

As I understood, JsonRPC interface is one of the primary reasons why SorobanRPC is separated from StellarSDK. If that's possible, it would be very desirable from the client developer's perspective to have everything in one package because right now most of the wallet developers have to import both SDKs, which unnecessary increases the bundle size for web projects. Having similar REST API and a single client SDK would be beneficial for ecosystem developers.

[near zephyr]

Having them in a single client is still slightly awkward if they are in two services horizon/rpc. But agreed about a single import

[lone arch]

JSON RPC is necessary for web3. A website with a crappy JS library is going to do "direct to node" calls. The alternative is to make protocol relay/route dedicated nodes that receive payment just for adding a large number of poor quality protocols and receiving messages on them. (MQTT for example, other chains, etc)

The wallets could be forced to translate between JS and REST but 'the way people write code' in practice means that the REST requests are going to get multiple queries instead of one JSON RPC. I always prefer REST based access, but frameworks don't always agree.