4 ms·
>Go is more typically used for microservices deep within the backend (which may even use something like gRPC rather than HTTP) What are some criteria for using
by vram22 8y ago
>Go is more typically used for microservices deep within the backend (which may even use something like gRPC rather than HTTP)
What are some criteria for using (g)RPC vs. HTTP (if by HTTP you mean REST-style too)? I had read part of a series of posts about RPC vs. REST by Steve Vinoski (who was formerly involved with CORBA, IIRC), but that was some years ago, so 1) I don't remember his arguments well, and 2) the tech may have changed since then.
- closeparen 8y agoREST is not very structured and means something a little different to every implementer. Systems like Thrift and GRPC build an uambiguous contract around the request and response schema, with IDL serving as documentation whose correctness is mechanically enforced. Since both parties have the IDL, the messages can be packed efficiently on the wire without any field names and in formats that are less computationally intensive to parse/serialize than JSON. It’s also relatively clear which IDL changes are breaking and which are backwards compatible (the latter being the only kind you can sanely make in a running distributed system). The wire protocol can be less chatty and better suited to multiplexing a high volume of traffic along the same socket, which was a shortcoming of HTTP until relatively recently with HTTP2.
- vram22 8y agoThanks, makes sense.