louiscryan

Multiplexing RPCs onto a single WebSocket has some serious downsides. For one you now have an entirely custom protocol that standard proxies will not understand and cannot route. GRPC is very careful to be valid HTTP/2 for this reason.

One of the major reasons for the existence of WebSocket is to support duplex streaming. HTTP/2 explicitly states

"A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received"

With better HTTP APIs (particularly in the browser) you would get full-duplex and the need for WebSocket would diminsh.

This is an interesting an complex topic.

Kenton does a pretty good job discussing this here https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-...

and rightly mostly focuses on the message-encoding aspects. Performance will vary by use-case & platform and should be traded off against the suitability for the given use-case (platform support, schema evolution, fidelity of representation, maturity vs bleeding edge)

Cap'N'Proto has some interesting RPC features (promise-pipelining, pass-by-reference) that may be valuable to some.

FYI it would be perfectly reasonable to use Cap'N'Proto messages with GRPC as the transport layer to get HTTP2 support. GRPC was explicitly designed to allow for this.

Protobuf has better platform coverage than FlatBuffers and it's schema is easier to evolve but neither of these may matter for your use-case. As in all things it depends.

Websocket does framing at the application layer, not the transport layer. Its probably more accurate to say that websocket lets you send binary or text messages.

More specifically this means that multiple WebSockets are not multiplexed over a single TCP/IP socket. One physical connection per-Websocket is a real scalability issue for servers and proxies.

WebSocket-over-HTTP would address that. See the options being discussed here http://tools.ietf.org/html/draft-hirano-httpbis-websocket-ov...

That is certainly a goal for Websocket-over-HTTP2, though in truth it would be no cheaper than long-poll-over-HTTP2 and more expensive if you invented your own metadata mechanism rather than using HTTP2 headers. And as you say, less idiomatic.

Using separately addressable resources and having HTTP2 do the connection multiplexing for you seems like a good pattern to me.

HTTP2 is superior to WebSocket at the transport layer because it adds explicit framing support and other things. Websocket-over-HTTP2 is coming, but it's not here now.

While HTTP/1.1 was a poor transport for high-perf RPC there are many parts of it that make sense semantically (headers, trailers, mime-types, virtual-hosting, content-encoding specification etc). HTTP2 lets you continue to use those in a form everyone is familiar with, with Websocket you would have to invent them again.