#note #networking
quick take:
- grpc over http, rest over http, and graphql over http are protocols for data retreival from servers. Websockets are a low-level protocol from 2011 that can be supported more natively than, eg. gRPC, in the browser, for bidirectional streaming.
- Use grpc for featureful bidirectional streaming, when the client doesn't need to be http1.1 compatible (eg. in browsers)
- Use websockets for low-level bidirectional streaming from the browser, or else set up a grpc-web proxy server.
- Use graphql for complex, flexible database queries, especially useful in front-ends.
- Use REST for simplicity, and because libraries make it easy.
- skip to the end for some notes on the upcoming HTTP3, which communicates over UDP instead of TCP, and claims to reduce communication complexity.
I found this as a reference about why anyone bothers with stuff other than REST, and it raised some questions. https://blog.logrocket.com/graphql-vs-grpc-vs-rest-choosing-right-api/
This is mostly a comparison between REST and gRPC, with graphQL included for completeness in my notes, it's fine to ignore that section. My understanding of the comparison looks like:
- Good for simplicity and maturity, Rocket's interface is very clean
- Most http client libraries support edge caching OOTB, increasing cache efficiency (nice, but not our use case)
- Inflexible for updating database schemas (not our use case)
- limited backwards compatibility, relative to gRPC
- runs over HTTP/1.1: very legacy support, somewhat inefficient relative to HTTP/2
- somewhat more complex than REST, but Tonic (our grpc lib) has great codegen features, only slightly more complex to work with than Rocket
- more efficient communication: messages have more available types than REST, are packed as efficiently as possible, unlike JSON, thereby reducing communication load, and gRPC supports bi-directional streaming messages (our node-to-node signing communication weight isn't huge, so this is nice but not huge for us)
- limited browser support: because gRPC uses HTTP/2 (introduced by IETF in 2015), you may not be able to call a gRPC service directly from a web browser, unclear if also true on mobile.
To preface, I don't have any reference points on HTTP1.1 and HTTP2, so I don't know how relevant this is. It was advertised as an issue for browser compatibility, this may be a non-issue as this might be simply solved by supporting only newer browsers. I imagine mobile would be the same, but this seemed like a good point to sync on.
IANS, HTTP1.1 compatibility with gRPC would be a headache. If Alice wants to participate in signing, as we expect her to, she will have to submit gRPC messages, which require HTTP2 requests converted into gRPC requests. It looks like the established solution is to have a proxy translation layer to perform conversions between the client's requests on the browser/mobile into HTTP2, which can then be converted to gRPC messages.
See post on differences between HTTP/1.1 and HTTP/2.
- Good for flexible system of requests against a database schema (not our use case)
- Most complex tool of the three, benefits from good caching, but requires users to design schemas well to avoid duplicate/overlapping caching of request data--ie. you have to design schemas that don't suck (I did it, it's not that hard)
- My understanding is that it surpasses the others in terms of allowing flexible database queries, which is how I used it at mintbase, but for systems of predictable communication patterns (eg, what we're doing) is overkill
Forgot what web sockets were. We used the analogy in CR of a WS high five versus a HTTP handshake (which now seems somewhat backwards). Apparently Rocket doesn't support WS. They're duplex communications over a single TCP conn, standardized in 2011. Distinct from HTTP, not HTTP. Both are application layer protocols over TCP, Web socks are compatible with HTTP proxies. BUT after the release of HTTP in 2015, Websockets are a narrow protocol, to only be used for high speed duplex communication. See this page for a useful table of comparisons. HTTP2 was standardized in 2015, adding support for keeping blocking port connections open and listening for updates, by server-pushes. WebSockets are also generally lower level than http2.
In 2011, the answer might have been that, Websockets' distinct features include:
- lower overhead than half-duplex alternatives, facilitating bidirectional data transfer
- when use: efficient duplex streaming communication, at the cost of blocking the port, when working with real-time data streams.
Note that gRPC (which also claims to achieve efficient bidirectional streaming data transfer), uses HTTP2 as the underlying transfer protocol. This means that web applications using gRPC clients cannot live inside browsers, but can be put behind a proxy.
proxy aside
This means that the browser must use a minified grpc-web client, compatible with HTTP1.1 and 2, send requests to a grpc-web proxy server, which translates messages to and from grpc-web to grpc, before handing them off to the grpc server.
grpc was released in 2016, shortly after HTTP2, adding features, including:
- highly performant, moreso than REST
- authentication
- bidirectional streaming (same as web sockets) and flow control,
- nonblocking bindings (unlike WS)
- cancellation and timeouts
- a healthy dose of language independent code generation
- multilanguage support Best examples of use cases include microservices and efficient mobile client connections to servers.
HTTP/2 addressed the Head-of-line blocking - Wikipedia issue in HTTP1, briefly that a line of packets in a queue are blocked by some processing blocking by the FIFO front packet. There's still an issue of TCP-blocking inefficiencies, thus the decampment to UDP for better concurrency primitives, over a more condensed handshake-auth-data-transfer protocol.
HTTP/3 would solve issues of handshake overhead and blocking by using
- QUIC > TLS to handle authenticated, encrypted streams
- UDP > TCP at the transport layer.