Hacker News Reader

We use jsonrpc over ws on f/e-b/e and between b/e-b/e services in trading system, typescript types for api, runtime type assertion combinator library for io boundary type checks, backend teams co-maintain client libraries to access the service, it works very fast, it is safe and easy to maintain/track changes etc.

View on HN

JSON-RPC is my protocol of choice as well. I feel most of these other protocols are mostly an exercise in information exchange theory which make them too idealistic, resulting in poor implementations that do not follow the standard or are extended in non-conforming ways.

In the end you simply want to interact with the client or server and procedure calls do just that. I honestly do not see the use in over complicating that.

I've used jsonsprc a few times and my experience was excellent (opposite to GraphQL, actually).

But the jsonrpc endpoint had good documentation and the client library didn't feel alien to the project, like a big query string embedded in the client code.

I wonder why jsonrpc is not used more often; but I guess compared to a REST API, the client may be more complicated.

Reply on news.ycombinator.com