I'm trying to understand the benefits of using GRPC with its strong typing and contract enforcement compared to REST in practice, especially between two teams managing separate microservices. For instance, if team A creates a service and team B consumes it, wouldn't team B need to build an interface (like a C# class) to handle the JSON responses from team A? This situation seems similar to how sharing .proto files would work. So, what's the real advantage of using .proto files? I do recognize that other benefits exist, like faster binary communication and easier modeling of complex operations beyond just GET and POST, but I'm still unclear about the core advantages of the .proto file itself.
4 Answers
Based on my past experiences with REST APIs, I've found JSON quite flexible. However, I've also faced frustrations when services frequently changed their JSON structure without proper versioning. It can be difficult to keep up when the other team is constantly modifying the API. In such scenarios, using protobuff can feel like more of a burden since it ties you closer to the other team's changes, whereas I often prefer to create my own model that just caters to what I need. That way, even if they change things on their end, my service can adapt more easily.
This is often referred to as 'contract first' development. You define your interface first and generate the necessary code for clients and servers. REST has something similar with OpenAPI (formerly known as Swagger), which helps maintain the contract akin to .proto files.
If you want to make the most out of GRPC, using a client code generator is a must! It streamlines the whole process and makes your life easier.
Totally agree! That applies to REST as well. You definitely want to automate as much as you can.
The real edge of using a .proto file is its language independence. If team A and B are both using C#, sure, they can share a model, but if they use different languages, that's where things get tricky. Each team would need to create their own version of the model to keep up with any changes, and that can introduce bugs or miscommunication about data formats. With protobuf, you only write the schema once, and from that, you can generate specific code for different languages. If the schema changes, just regenerate it! Plus, protobuf can be used without GRPC too; you can pass around its formatted data as needed, but GRPC just simplifies it all.
You might still run into problems with gRPC. If the .proto file changes improperly, it could really mess things up. But yeah, the main issues often stem from poor engineering practices rather than the technology itself.