Google's gRPC is actually a new take on an old approach known as RPC, or Remote Procedure Call, which has come a long way to stand out among Messaging, Queuing, COM, CORBA, SOAP, REST, and GraphQL in Microservice world.
Performance
gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC. Protobuf is about 3x faster than Jackson and 1.33x faster than DSL-JSON for integer encoding. gRPC uses HTTP/2, it can multiplex multiple RPCs on the same TCP connection. gRPC supports bidirectional streaming. Therefore, gRPC has low latency and high throughput.
For in-depth analysis of gRPC vs REST, please visit https://medium.com/@EmperorRXF/evaluating-performance-of-rest-vs-grpc-1b8bdf0b22da.
Interoperability
gRPC's IDL (Interface Description Language) provides a simpler and more direct way of defining remote procedures than OpenAPI's approach of using URL paths, their parameters, and the HTTP methods that are used with them. It is a cross-platform/multi-language framework.
Stability
In addition to gRPC is language-neutral, platform-neutral, and
extensible, gRPC mitigates Microservice and Distributed Communication pitfalls.
gRPC IDL is more stable than REST over time. REST or OpenAPI use HTTP verbs
(GET, PUT, POST) and payload (usually JSON).
.NET Integration
Speaking of .NET, gRPC is very easy to integrate with ASP.NET Core. Please refer C# 8 new feature Async Streming. However all things are shiny. Some .NET data types are not supported. The tooling is behind Web APIs in Visual Studio and Postman. For the UI facing (JavaScript in browser, not nodejs), the services have to be built in Web APIs.
In the end, I have to come to the conclusion – gRPC might be
a success in performance critical Microservices but it will not replace
REST/Web APIs.
We will see.
No comments:
Post a Comment