4 ms·
What about HTTP/2 Multiplexing, how does it hold up against long-polling and websockets? I have only tried it briefly when we use gRPC: https://grpc.io/docs/wh
by peheje 2y ago
What about HTTP/2 Multiplexing, how does it hold up against long-polling and websockets?
I have only tried it briefly when we use gRPC: https://grpc.io/docs/what-is-grpc/core-concepts/#server-streaming-rpc https://grpc.io/docs/what-is-grpc/core-concepts/#server-stre...
Here it's easy to specify that a endpoint is a "stream", and then the code-generation tool gives all tools really to just keep serving the client with multiple responses. It looks deceptively simple. We already have setup auth, logging and metrics for gRPC, so I hope it just works off of that maybe with minor adjustments.
But I'm guessing you don't need the gRPC layer to use HTTP/2 Multiplexing?
- toast0 2y agoAt least in a browser context, HTTP/2 doesn't address server to client unsolicitied messages. So you'd still need a polling request open from the client. HTTP/2 does specify a server push mechanism (PUSH_PROMISE), but afaik, browsers don't accept them and even if they did, (again afaik) there's no mechanism for a page to listen for them. But if you control the client and the server, you could use it.
- yencabulator 2y agogRPC as specced to ride directly on top of HTTP/2 doesn't work from browsers, the sandboxed JS isn't allowed that level of control over the protocol. And often is too low level to implement as part of a pre-existing HTTP server, too. gRPC is a server-to-server protocol that is not part of the usual Web, but happens to repurpose HTTP/2. Outside of gRPC, just HTTP POST cannot at this time replace websockets because the in-browser `fetch` API doesn't support streaming request body. For now, websockets is the only thing that can natively provide an ordered stream of messages from browser to server.
- BitPirate 2y agoWith RFC8441 websockets are just HTTP/2 streams.