3 ms·

> There are quite a few factual errors in this post, like [...] no streaming in REST (not necessarily true). Where did it say that? I got the opposite impressi

by cle 3y ago

> There are quite a few factual errors in this post, like [...] no streaming in REST (not necessarily true). Where did it say that? I got the opposite impression: > Handling large data sizes with REST APIs, such as file uploads, is rather straight forward. The received file can be treated as a stream, using very little memory. Re: streams, I've found that an opaque binary stream in REST is okay, but the moment I want to stream messages, my life is hell. I keep running into this, and it's such a pain. If I have to stick with REST, I end up inventing a bespoke RPC protocol to allow for sending errors as part of the stream, either as part of the message or as a trailer header (and trailers have their own issues like no browser support). And then the semantics of HTTP status codes have to change. The reason I often stick with REST is that infrastructure supports HTTP/1 much better than h2/gRPC (such as L7 load balancers, caching, etc.). JSON RPC is not always a good answer either as caching POSTs is typically not well-supported and using GET with JSON RPC is discouraged and fraught with issues. I would definitely prefer to just use gRPC but the poor middlebox support sometimes makes it cost-prohibitive. What a mess.

danpalmer 3y ago
From the article: "This is a very nice advantage of gRPC in comparison to REST, which only supports unary requests." You're right that files can be streamed and it does say that, but additionally there's no reason why messages can't be streamed down an open connection. Out of interest, as I hadn't considered middlebox support, what sort of things do you find becomes problematic? Doesn't TLS mitigate that? Or are you thinking of niche environments like companies that require intercepting all traffic on their networks? I realise those use-cases do exist, but they're pretty uncommon now as more people realise they're terrible security practice.
- cle 3y ago
  I'm talking about L7 middleboxes like HTTP load balancers, API gateways, caches/CDNs, etc.
  - danpalmer 3y ago
    Oh fair enough. I guess that's true, although I'm not sure I'd see too much of a problem there. For load balancers there are options that work fine with gRPC, similarly API gateways. Caches and CDNs no (at least I haven't seen any), but then again, I'm skeptical about putting CDNs in front of business logic, and would only ever use them for actual content (where the serving logic doesn't matter). Even logged out usage of APIs still often has analytics and other stuff that means you want to hit the backend every time.

by cle 3y ago

danpalmer 3y ago

From the article: "This is a very nice advantage of gRPC in comparison to REST, which only supports unary requests." You're right that files can be streamed and it does say that, but additionally there's no reason why messages can't be streamed down an open connection. Out of interest, as I hadn't considered middlebox support, what sort of things do you find becomes problematic? Doesn't TLS mitigate that? Or are you thinking of niche environments like companies that require intercepting all traffic on their networks? I realise those use-cases do exist, but they're pretty uncommon now as more people realise they're terrible security practice.

cle 3y ago
I'm talking about L7 middleboxes like HTTP load balancers, API gateways, caches/CDNs, etc.
- danpalmer 3y ago
  Oh fair enough. I guess that's true, although I'm not sure I'd see too much of a problem there. For load balancers there are options that work fine with gRPC, similarly API gateways. Caches and CDNs no (at least I haven't seen any), but then again, I'm skeptical about putting CDNs in front of business logic, and would only ever use them for actual content (where the serving logic doesn't matter). Even logged out usage of APIs still often has analytics and other stuff that means you want to hit the backend every time.