[klabb3]

> - JSON RPC code generators are non-existent or badly maintained depending on the language.

Very much so. It’s in a terrible state where I’ve looked. Most of the tooling is by OpenAPI or similar which comes with a bloatload of crap that is only marginally better than say SOAP. It needs to be much simpler.

> - Not binary like Protobufs or similar

Agreed. This is not an issue for small things that can be base64 encoded but once you need large blob transfers you don’t have any reasonable option. This is a problem in eg graphql which also misses the mark and you have to step outside for things like file uploads.

It feels like the whole standardization effort around json rpc is weak. It doesn’t address the needs of modern RPC-like systems. Which is unfortunate because there’s a real opportunity to improve upon the chaos of REST.

[tornato7]

It's not ideal, but in practice GZIP base64 is only marginally larger than GZIP binary

[klabb3]

Indeed, good point, and worth clarifying. A lot of people think the size overhead is the problem, which usually it isn't, like you say, because of fairly cheap compression.

However, the main issue with big base64 blobs is that you can and should never assume that JSON parsers are streaming. So you may need to load the whole thing in memory, which of course isn't good.

Note that I'm not necessarily blaming JSON for this. My gut feeling is that crusading for streaming parsers is a Bad Idea. Instead, this is something that should probably be a higher-level protocol, either by streaming chunks (a la gRPC) or by having separate logical data streams (see e.g. QUIC). JSON RPC does not, afaict, solve these issues.

[hotfix_cowboy]

Base64 multiplies the GZIP size by 1.33x (4/3, or a 33.3% increase in size)

SO (https://stackoverflow.com/questions/4715415/base64-what-is-t...)

[tornato7]

That's for Base64-encoded GZIP, not GZIP-encoded Base64 :)

[nine_k]

Have you tried zstd, now widely supported?