I have been spending many years working with gRPC and Protocol Buffers (protobuf) for microservices architecture. Typically, many people, myself included, use gRPC with protobuf in an intuitive way to share the server contract. For me, gRPC services and protobuf definitions represent the next generation of server-client implementation. For a long time, people were entangled with technologies like Swagger, OpenAPI, and JSON schema for HTTP. With HTTP/2, we began adopting new technologies that manipulate binary data streams to deliver the fastest performance.
This performance tweaking can be immensely beneficial. The decrease in transaction time saves you from the pressure of fault tolerance over a period. Additionally, from enterprises’ perspective, a smooth user experience (UX) can be ensured with this improvement.
The way we are developing gRPC applications
I have been using the gRPC framework for a while. gRPC has been actively developed and battle-tested through use cases at Google. Despite the fact that the gRPC framework has many advantages, it is challenging to apply it in the real world due to some reasons.
One of the reasons is that your client technology and frontend developers sometimes cannot adapt to the new technology. For many startup enterprises, choosing a technology that is future-proof can save you a longer path to the future. However, to be compatible with the current developers’ situations, we may need to consider a solution that provides the ability to quickly plug and play for the client first. After that, we can proceed with other plans. We definitely cannot afford the time for testing the new technology because despite the fact that the gRPC client can be generated and used with the frontend immediately, every new technology may require a different set of debugging experiences to handle and develop it.
In order to resolve those problems, for every team using gRPC, we must implement a sidecar service with gRPC gateway to translate the HTTP/1 request/response to protobuf binary streams and handle them. For internal communication between backend services, we can use gRPC calls seamlessly because we understand how the technology can be leveraged to reduce transaction time. gRPC gateway can also be easily extended with many available plugins, such as payload logging, authentication, metrics, and tracing solutions.
However, I cannot say that I love the development of the gRPC gateway because I have been working with it since its first versions. The interface keeps changing every time I upgrade the core library. Another reason is that it adds a topping layer to your application, making the transport benefits vanish.
The development of the gRPC gateway ecosystem is still in a limited state; the plugin openapiv2 was developed a long time ago, and they haven’t upgraded it to support OpenAPI v3. If you are struggling with this, you can give this tool a try.
Though there is no official announcement or tutorial for this project, I found it very helpful when you want to revamp your documentation for the next version.
ConnectRPC
Therefore, if you are an innovative developer or a startup, I think you should give ConnectRPC, the next framework created by the Buf team, a try.
Connect is a family of libraries for building browser and gRPC-compatible HTTP APIs: you write a short Protocol Buffer schema and implement your application logic, and Connect generates code to handle marshaling, routing, compression, and content type negotiation. It also generates an idiomatic, type-safe client in any supported language.
The goal of this platform is to help us build a server that can handle all types of low-level protocols like HTTP 1–2–3 while keeping the interface simple enough for developers to quickly develop their applications. I have started a project using this and achieved ease of development.
- It has a lean interface and offers high customization anytime if you want a feature to be compatible with each specific low-level protocol (e.g., set a custom HTTP status code for HTTP/1 compatibility).
- You only need to manage a single server instance. Not an extra processor.
- The new Connect protocol is easy to work with (a little bit like Twirp), making the client compatible and easily upgradeable when you decide to move to use HTTP/2 and HTTP/3 infrastructure.
- The interceptors are up-to-date with the current status of Go development (using generics and Google’s cel-go, which I find pretty lovely).
You can find some examples of making ConnectRPC work on its homepage. I think you may find it surprising to get a server that supports many use cases, what we need to work with the gRPC framework, in just a few lines of code.
curl \
--header 'Content-Type: application/json' \
--data '{"sentence": "I feel happy."}' \
https://demo.connectrpc.com/connectrpc.eliza.v1.ElizaService/Say
grpcurl \
-d '{"sentence": "I feel happy."}' \
demo.connectrpc.com:443 \
connectrpc.eliza.v1.ElizaService/SayThe protocol may end up with some weird addresses like above. However, I have been a fan of RPC over REST for some time because I realized that it’s pretty hard for me to encapsulate all the use cases that I have down to only some HTTP verbs and object relationships in REST principles.
Conclusion
Recently, the Buf team announced their new project, ConnectRPC. I had a chance to try it, and it fits my needs really well, and the architecture is fairly lean and extensible. It can be a great alternative if you are looking for something to replace the gRPC gateway or a great implementation for your gRPC application.
