4 ms·
HTTP2 is not a suitable protocol for implementing persistent, stateful communication channels. HTTP2 is bidirectional but it's stateless. gRPC is bidirectional
by applepple 5y ago
HTTP2 is not a suitable protocol for implementing persistent, stateful communication channels. HTTP2 is bidirectional but it's stateless. gRPC is bidirectional but intended to be stateful. WebSockets (bidirectional and stateful) would have been a better match and not required sticky sessions. gRPC essentially takes us back to the dark ages of long polling.
I was making this argument for years. WebSockets was designed for bidirectional data exchange between client and server. On the other hand, HTTP2 was designed for pushing static resources to the client to speed up loading of front ends (it was meant to make bundling front-end scripts redundant). HTTP2 was not designed for bidirectional data exchange over a stateful channel.
- ffk 5y agoI believe grpc only uses the http2 frames, which are bidirectional. Double check this though.
- applepple 5y agoBased on the article and the fact that they implied that sticky sessions are necessary, it doesn't seem that the abstraction is airtight. If it was properly stateful, then sticky sessions would not be required. With WebSockets, sticky sessions are not required when load balancing.
- jayd16 5y agoIt's not sticky sessions in the traditional sense. It's a single connection. Http/1.1 requests are allowed to be stateful within a single connection as well. The difference is there is built support for multiplexed requests within that single connection.
- jayd16 5y agoCan you be more specific? What technical drawbacks are relevant? It's certainly not literally polling any more than a websocket so what do you mean? Long running websockets are also hard to balance for the exact same reasons. Much harder in fact because you can't use a per request LB.