We already have the Twrip-RPC which provides rpc and rest endpoints . then why we need the grpc-Gateway . What advantages it's providing compared to twirp. Is it like we can provide custom endpoints with grpc gateway is that the only difference. what grpc-gateway which Twrip-rpc can't do?
3 Answers
Twirp and gRPC gateway are similar. They both build API services out of a protobuf file definition.
Main differences:
- gRPC only uses protobuf over HTTP2, which means browsers can't easily talk directly to gRPC-based services.
- Twirp works over Protobuf and JSON, over HTTP 1.1 and HTTP2, so any client can easily communicate.
- gRPC is a full framework with many features. Very powerful stuff.
- Twirp is tiny and small. Only has a few basic features but it is a lot easier to manage.
Twirp supports JSON-encoded requests and responses in addition to the binary Protobuf-codec while it still behaves as an RPC. You can use HTTP POST on an endpoint like /twirp/MyService/SayHello with a JSON payload and receive a JSON response. Very similar to standard gRPC except optionally JSON.
For gRPC Gateway it's a little different. Here you can configure any HTTP REST endpoint on existing gRPC service. For example, MySevice.SayHello can map to GET /hello. This makes it very easy to implement a complete REST service on top of your gRPC definitions.
Hope this clarify it.
To generate the RPC scaffold using the RPC framework for Go RPCs, we can consider gRPC from the beginning or look towards a more simple Twitch RPC, i.e. Twirp.
Common reasons for choosing Twirp over gRPC are as follows:
- Twirp comes with HTTP 1.1 support.
- Twirp supports JSON transport out of the gate.
- gRPC re-implements HTTP/2 outside of net/http.
And reasons for gRPC over Twirp are:
- gRPC supports streaming.
- gRPC makes wire compatibility promises.
- More functionality on the networking level.
Related