11–20 of 139 posts
A benefit of grpc coming to the web means someone will inevitably build a tool to parse a .proto file and generate a ui to test your microservices during dev. That will be cool.
There is a reason why more and more people left RPC and use REST. And for me "the next big thing" is something like GraphQL.
There is a reason why more and more people left RPC and use REST. And for me "the next big thing" is something like GraphQL.
REST was a breath of fresh air after SOAP, but unfortunately it is an incomplete solution and leaves too many unsolved problems in user-space. This has led to a proliferation of attempts to build standards on top of REST, such as JSON-API. When we're building systems, RPC is a more natural fit because the semantics are clearly defined.
There is a reason why more and more people left RPC and use REST. And for me "the next big thing" is something like GraphQL.
Imo it was mainly poor language / framework support for asynchronicity. That's not really an issue anymore.
* Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility.
* Zero discoverability. The client knows in advance what the server can do.
* No standards to follow. You make up your own specs, like Google did.
These constraints are orthogonal to REST, the architectural principles behind the web. What they're doing is tunneling RPC over the web, which is what most HTTP APIs are doing already. There are only superficial differences like the use of protobuf, lack of verbs and URIs, etc.
I think I like gRPC, but have several reservations regarding replacing REST with it. REST web services often return multiple mime formats, not just pure structured data. Some services return images, others return HTML, and then you also have cache... Maybe I just don't know enough about gRPC, but I can already imagine many people passing images around as byte arrays inside protocol buffers and when we look back, we h…
In fact that's what Google's API design guide does. Encourages RESTful API design then describes how to implement them using proto and gRPC.
The more interesting tradeoffs are proto vs json or other and how this restricts message patterns to request/response (rather than pub/sub or push/pull)
Earlier quoted context omitted.
Imo it was mainly poor language / framework support for asynchronicity. That's not really an issue anymore.
So how is the modern way to work around issues like network partitions, servers not responding, going off and on on network connections, duplicate answers,....?
This paper says that exactly once execution of an RPC is possible. I have no idea if grpc does this or not.
RPC has its own set of limitations, which if your application qualifies, might be a good fit: * Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility. * Zero discoverability. The client knows in advance what the server can do. * No standards to follow. You make up your own specs, like Google did. These constraints are orthogonal to REST, the architectural principles behind the…
Either I misunderstand you, or this is _remarkably_ wrong: Protocol buffers were designed to make it easy to define protocols which are both backward and forward compatible.
I only skipped through the spec for gRPC, but the protocol seems very limited. I dont like the 'gRPC status codes', where HTTP status codes at least can be grouped in ranges.
The abstraction from the technology/protocol should not be the issue compared to the abstraction from the core business logic. When handling multiple consumers, customers and technologies I tend to worry more about where logic is handled and where data is stored, compared to how its transferred.