3 ms·

Thrift and gRPC can "push" until the cows come home (streaming). Use the correct tool for the job. HTTP is for hypertext documents, not APIs or RPC.

by zelly 6y ago

psanford 6y ago
Well, gRPC uses HTTP/2 as its default transport so I'm not sure "HTTP is for hypertext documents" is valid. Note that gRPC never used HTTP/2 PUSH_PROMISE frames so it isn't affected by their removal. gRPC's bi-directional streams have to be initiated by the client.
abofh 6y ago
And telephones are for phone conversations, not squealy modems! Use an ISDN line like god intended!
- zelly 6y ago
  this but unironically
rswail 6y ago
HTTP is for REST, REST is an API style for client/server interactions. RPC is another API style, but it's more tightly coupled. RPC has been tried and tried and tried and the same problems happen all the time. Tightly coupled, brittle, hard to upgrade. If by "gRPC" you meant protobuf as a message format, then sure. But TLV based binary streaming has been around for yonks (eg ASN.1). Pushing is an optimization to avoid API round trips, not just the capability of sending a binary stream. Link headers have the same effect as HTTP/2 push, but a client can cache previous requests (and the new 103 Early Hints status). It's a hint from the server that it's highly likely that the Link URLs will have useful information in terms of the current request. It can be seen by caching layers between the client and the server, so they can pre-cache the links or deliver them without server interaction if previously cached. All of that is part of HTTP, which has nothing to do with "hypertext documents". It just happened to be that hypertext documents were the first use of the protocol.
- zelly 6y ago
  Most "REST" APIs are just RPC. Many "REST" URLs are just the names of the methods they call on the remote endpoint. REST is good for things like downloading and uploading documents or media to a web server. GET, PUT, POST, DELETE, etc. were designed for documents/media. Because it's available from a web browser, like JavaScript, people started using it even on native apps because it's familiar. That doesn't mean it's the best or most productive protocol.

Thrift and gRPC can "push" until the cows come home (streaming). Use the correct tool for the job. HTTP is for hypertext documents, not APIs or RPC.

by zelly 6y ago

Thrift and gRPC can "push" until the cows come home (streaming). Use the correct tool for the job. HTTP is for hypertext documents, not APIs or RPC.

psanford 6y ago

Well, gRPC uses HTTP/2 as its default transport so I'm not sure "HTTP is for hypertext documents" is valid. Note that gRPC never used HTTP/2 PUSH_PROMISE frames so it isn't affected by their removal. gRPC's bi-directional streams have to be initiated by the client.

abofh 6y ago

And telephones are for phone conversations, not squealy modems! Use an ISDN line like god intended!

zelly 6y ago
this but unironically

rswail 6y ago

HTTP is for REST, REST is an API style for client/server interactions. RPC is another API style, but it's more tightly coupled. RPC has been tried and tried and tried and the same problems happen all the time. Tightly coupled, brittle, hard to upgrade. If by "gRPC" you meant protobuf as a message format, then sure. But TLV based binary streaming has been around for yonks (eg ASN.1). Pushing is an optimization to avoid API round trips, not just the capability of sending a binary stream. Link headers have the same effect as HTTP/2 push, but a client can cache previous requests (and the new 103 Early Hints status). It's a hint from the server that it's highly likely that the Link URLs will have useful information in terms of the current request. It can be seen by caching layers between the client and the server, so they can pre-cache the links or deliver them without server interaction if previously cached. All of that is part of HTTP, which has nothing to do with "hypertext documents". It just happened to be that hypertext documents were the first use of the protocol.

zelly 6y ago
Most "REST" APIs are just RPC. Many "REST" URLs are just the names of the methods they call on the remote endpoint. REST is good for things like downloading and uploading documents or media to a web server. GET, PUT, POST, DELETE, etc. were designed for documents/media. Because it's available from a web browser, like JavaScript, people started using it even on native apps because it's familiar. That doesn't mean it's the best or most productive protocol.