91–100 of 136 posts
Can one use nginx in front of a grpc serving backend if the client is a JS client in the broadest sense?
This unanswered question is the main reason I'm still doing RESTful JSON.
It seems like a lot of other technologies in this space have solved the listed problems while remaining compatible with browsers, load balancers, reverse proxies, etc. It was a product choice not to offer a fallback path when HTTP/2 was unavailable. That choice made gRPC impossible to deploy in a lot of real-world environments. What motivated that choice?
Earlier quoted context omitted.
My preferred setup is to have an unencrypted service running on 127.0.0.1 (so not publicly available), and then have nginx in front to handle certificates. Lets me do all certificate stuff across all virtual hosts in one place. HTTP/2 makes this impossible due to its ridiculous TLS requirement, so I, and everyone who does it the way I do, must keep using HTTP/1.1 forever. It's my belief that requiring TLS for HTTP/2…
> My preferred setup is to have an unencrypted service running on 127.0.0.1 (so not publicly available), Don't forget that JS from any webpage can access your 127.0.0.1 to various degrees. Depending on what types of requests exactly the server accepts, it may be somewhat unsafe for a machine with a browser.
On a machine with a browser, local servers are dangerous, HTTPS or not.
Earlier quoted context omitted.
They provide different APIs. Websockets provide a bidirectional stream of messages. The messages in a given direction are always delivered in order. If they were to be suddenly reordered that would cause a lot of headaches. While the individual messages can't be multiplexed, different websocket streams over a single HTTP/2 connection can be multiplexed. I think websockets also provides a feature that HTTP/2 doesn't:…
> I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript. I will never stop beating this drum: Server-Sent Events and EventSource! Simple to implement, scale, support. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource
Earlier quoted context omitted.
> I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript. I will never stop beating this drum: Server-Sent Events and EventSource! Simple to implement, scale, support. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource
Pardon my ignorance: Are messages sent through this guaranteed to arrive in order?
Author doesn't support the case for grpc being a "failure". I wonder by what measure. It's certainly pretty popular.
Being able to use gRPC in browsers was an explicit goal of the project, and that is impossible. gRPC-Web has to use a modified version of the protocol that has a limited feature set and performs worse for the reasons described in the article.
My experience in the early days of gRPC is that they seemed fairly unwilling to consider any need for an easy upgrade path for existing people using HTTP/1.1 at all.
The author touches on this at the end:
> Focus on customers. Despite locking horns with other orgs, our team had a more critical problem: we didn’t listen to early customer feedback.
I'm glad they realise it now because lots of us warned them about this at the time.
If trailers are used for things such as checksums, then the client must wait patiently for potentially gigabytes of data to stream to it before it can verify the data integrity and start processing it safely.
If the data is sent chunked, then this is not an issue. The client can start decoding chunks as they arrive, each one with a separate checksum.
Earlier quoted context omitted.
This doesn't match what I see in the gRPC spec. It says every message must be length-prefixed. https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.... Disclaimer: I don't know much about gRPC.
I've spent a fair bit of time working with gRPC, and you're correct - gRPC's length-prefixing makes it easy to detect when individual messages are terminated early. You do still need some way to detect streams that terminate unexpectedly on message boundaries - perhaps you could rely on HTTP/2 EOS bits as evidence of an application-level success, but you need some equivalent of trailers to communicate the details of…
He explains the problem that caused this, in his opinion, in the article, but not very obviously. The problem is protobuf encoding. It's key-length-value (key identifies the field that follows, length is the length of the value, value is the value). A message is thus "KLVKLVKLVKLVKLV".
The second thing is that repeating a key is always valid (not just when it's declared as an array of values). If a field is repeated but it's not an array, then the newer value overrides the previous one.
(this was done so that if you have 20, or 2000000, massive protobuf files listing, say, urls visitors used, and you need to combine them, you can just concatenate the bytes together and read in the result as a valid protobuf. Also it means you do streaming reads of any protobufs coming in)
So:
1) you don't know when the message ends because you don't have a length field for the entire message (only for individual fields)
2) you don't know the message ends after a given number of fields, for 2 reasons. A, some fields are optional, and may or may not be present. B, even if all fields were sent, a newer version of an already-sent field might be sent to override the previously sent value.
You're right, of course, that the problem can be fixed by only allowing a single top-level message that is decoded in a nonstandard way (and frankly support for this could be added to the official protobuf libraries and it can be made to work by making this requirement optional ... Even concatenating can still be possible that way)
The problem here is rigid, immovable adherence to their own standard (ie. not incorporating a change like demanding KLV on the top level message in an RPC connection, or having a special concat-compatible, one-field-at-a-time decoding, because an architectural decision made 15 years ago said not to do this. Then make this mode required for the HTTP case)
This was an organisational problem. Not that they don't trust each other (obviously a browser developer doesn't trust many people, security really demands they don't. This is not where the problem is). GRPC failed to consider the fallout of them choosing the nuclear option of just dropping out of browsers in order to satisfy an old internal requirement without modifying their design. They chose this outcome, because they couldn't deal with achieving 99.9% of their aims as opposed to 100% ... and missed one of their main aims, let's say they achieved 50% instead.
I had never heard of HTTP trailers. So FYI > The Trailer response header allows the sender to include additional fields at the end of chunked messages in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr...
https://datatracker.ietf.org/doc/html/rfc2616#section-3.6.1
Ever went to some site that generates compressed downloads or database exports on the fly, got no progress bar as a result, and were severely annoyed by that lack of feedback? I was, so I used chunk extensions to submit a draft to emit progress information dynamically:
https://datatracker.ietf.org/doc/html/draft-lnageleisen-http...
As noted at the end of the draft, this could be generalized and extended to have additional capabilities such as in flight integrity checks, or whatever you can think of.
> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer protocols. WebSocket can run on top of HTTP/2. It's like saying TLS is technically superior to TCP, or IP is superior to copper cables. Reference: https://www.rfc-editor.org/rfc/rfc8441.html
The idea here is that http provides something like request/response semantics, methods, path, status code, etc - which are all also useful for gRPC. Websockets provide none of that - they are just message streams. Websockets over http/2 are a new thing, and haven’t even been available at the time gRPC incepted.
As far as I know for HTTP/3 there is no way to use websockets yet.