GRPC vs. REST in practice between teams
Posted by makeevolution@reddit | learnprogramming | View on Reddit | 5 comments
I'm still not sure about the advantage of GRPC being strongly typed and clients and servers are forced to have the same contract. I mean let's say there's team A and B managing different microservices. If we use REST, team B still needs to create an interface (e.g. a csharp class) to model the incoming JSON from team A. So thus team A has to share their model. So this wouldn't be the same as sharing .proto files between the two? How is then having a .proto file beneficial?
Although I do get the other benefits (using binay makes things faster, can model complex operations like "deactivate" without forcing yourself to fit to REST's GET. POST, etc.)
IndependentOpinion44@reddit
If you’re using GRPC without some sort of client code generator, you’re doing it wrong.
_Atomfinger_@reddit
At this point: This also applies to REST tbh
BoBoBearDev@reddit
Based on my horror experience on RESTful API, I will say, I personally I find JSON more free spirited than protobuff which I know little about (I used it for awhile, but not enough).
The biggest problem I run into is the service I am calling is freaking annoying, they keep changing the JSON without proper versioning. And even if they did versioning, they keep deprecating the version I am using. It is freaking annoying.
The service is maintain by another team(s) and they keep updating their services in the production k8s, so, my services keeps talking to this ever changing service. What's so bad is, they keep changing the JSON. Like moving properties from child to parent (so fucked up), adding more stuff (adding is not a big issue), removing properties.
Now, my service didn't need the entire JSON. So it is not a 100% coupled. Plenty of times, they are changing things that isn't used by my service, so it is not a big deal. If I nuget the model from their service or using protobuff, I am heavily coupled. Every time they changed something, my service cannot parse the JSON.
These days, I prefer just make my own model to parse the JSON and just ignore all the values I don't use. Obviously they can still fuck me up by changing the property I am using, but I run into less problems.
d-k-Brazz@reddit
This is called “contract first” - you define a contract, then you generate server stubs and give the contract to all the clients.
For REST you can use OpenAPI (Swagger). It will work the pretty similar to .proto
teraflop@reddit
The main advantage of a .proto file over your approach is that it's language-independent.
If team A and team B are both using C#, then they can just share a C# model class (and agree on the precise way to map that class's properties to JSON object properties).
If team A is using C#, and team B is using Java or Python or Go, then team B will have to reimplement their own version of team A's model, and keep it up to date whenever the model changes.
With protobuf, you write the .proto file once and then you can automatically generate language-specific bindings. If the schema changes, you just rerun the generator.
Of course, protobuf is not the only tool that can do this. There are similar tools for other methodologies and formats, e.g. Thrift, OpenAPI, and older technologies such as WSDL.