twirp VS gRPC

- 2. serialization format via protobuf

For most companies, neither 1 or 2 is needed, but the side effect of 2 (of having structured schema) is good enough. This was the idea behind twrip - https://github.com/twitchtv/twirp - not sure whether this is still actively used / maintained, but it's protobuf as json over HTTP.

Twirp is lovely, we kind of hit a wall when using it internally because it doesn't have a streaming story: https://github.com/twitchtv/twirp/issues/3

If you don't need to stream data it is excellent.

Graphql is by far the most painful DX and least productive thing I've seen cargo-culted. Like most things there's a time and place for Graphql but I think it's vastly overused.

For backend services in particular literally anything else is probably a better choice - rest, grpc, soap, a socket. I honestly don't know why more people don't give twirp a shot.

https://github.com/twitchtv/twirp

The next time I want to build an API, I will probably make use of https://github.com/twitchtv/twirp. I like working with Protobuf and having strongly-typed and well-defined messages, but gRPC is way, way too much. It's obviously a Google product, built for what Google needs.

Use Protobuf for messages, but just use HTTP for transport.

- Twirp (Twitch light version of gRPC, with optional JSON encoding, HTTP1 support and without streaming) - https://github.com/twitchtv/twirp

There is another: twirp

Recently, I started working on extending the support for gRPC in GoFr, a microservices oriented, Golang framework also listed in CNCF Landscape. As I was diving into this, I thought it would be a great opportunity to share my findings through a detailed article.

I recently faced this issue while wanting to use the pyi file generation feature in the rules_proto_grpc_python rule set.

Apache Arrow Flight RPC : Arrow Flight is an RPC framework for high-performance data services based on Arrow data, and is built on top of gRPC and the IPC format.

gRPC Official Site: https://grpc.io/

Connect fully supports the gRPC protocol, including streaming, trailers, and error details. Any gRPC client, in any language, can call a Connect server, and Connect clients can call any gRPC server. We validate our gRPC compatibility with an extended version of Google's own interoperability tests.

Generally used in conjunction with gRPC (but not necessarily), Protobuf is a binary protocol that significantly increases performance compared to the text format of JSON. But it "suffers" from the same problem as JSON: we need to parse it to a data structure of our language. For example, in Go:

grpc.io

We can take the previously mentioned idea of partitioning the database further by breaking up an application into multiple applications, each with its own database. In this case each application will communicate with the others via something like REST, RPC (e.g. gRPC), or a message queue (e.g. Redis, Kafka, or RabbitMQ).

Aside from the obvious differences in client library nomenclature and use of different credentials, API usage is fairly similar. Not visually obvious is that the older platform client library calls the REST versions of the GCP APIs whereas the newer product client libraries call the gRPC versions which generally perform better... yet another reason why the product client libraries are always recommended.