This is nice in that it brings up some design issues with proto-like formats for RPCs. I’d very much like to know what it would take for a format to replace JSON for the client-to-server scenario. It seems like one of the big issues is that most of the key advantages don’t apply or aren’t available yet.
(Using a binary format is really supposed to be more about resources required at the endpoints, not about wire size. As this author observes, gzip makes the wire size advantage very minimal… but gzip takes CPU to execute, and then a second buffer is needed to hold the expanded copy, and then it has to be parsed. The parsing actually probably dwarfs the gzip in CPU needed. But this is irrelevant on the client, because the client is only doing one of these at a time, so it has far more resources than it needs.)
This is nice in that it brings up some design issues with proto-like formats for RPCs. I’d very much like to know what it would take for a format to replace JSON for the client-to-server scenario. It seems like one of the big issues is that most of the key advantages don’t apply or aren’t available yet.
(Using a binary format is really supposed to be more about resources required at the endpoints, not about wire size. As this author observes, gzip makes the wire size advantage very minimal… but gzip takes CPU to execute, and then a second buffer is needed to hold the expanded copy, and then it has to be parsed. The parsing actually probably dwarfs the gzip in CPU needed. But this is irrelevant on the client, because the client is only doing one of these at a time, so it has far more resources than it needs.)