gRPC is a “remote procedure call” system that initially was developed by Google, counterintuitively Google claims the g in gRPC does not stand for anything Google related, but come on, we know it does

gRPC is a high-performance open-source RPC framework than can be used by almost any language. Most popular languages are supported with already written libraries and new ones are created every month.

What does gRPC solve?

gRPC makes calling services on other applications or servers very easy, it is based on Protocol buffers so you are able to create a very clear interface and service description with .proto files, and these proto files can then very easily be generated into servers and clients.

It is based on HTTP/2, so that means we have an open connection to the client giving us the ability to use Request/Response patterns, gRPC also supports
bidirectional event streaming, flow control, blocking or nonblocking async calls. Meanwhile having cancellation and timeouts built right into the core framework.

Basically, gRPC gives you everything that your microservice, webserver or client needs to quickly spin up a client/server relationship, with a fully described interface or “protocol” between them.

Gone are the days where different microservice teams, or 3rd party developers are asking you to create client program for their specific need. Just give them the `.proto` file and they will be able to generate a client that is fully compatible.

What makes gRPC so great?

Not only is gRPC great because it gives you everything you need out of the box, it is also blazingly fast and efficient.

Since gRPC is using Protocol buffers for its’ serialization layer, the messages that are sent between services are extremely small and compact, because they are compressed and only contain the data, not the structure of the messages. This means that compared to JSON, protobuf messages are between 65% to 80% smaller than the same object represented in raw JSON.

Protocol buffers are also extremely fast to serialize and deserialize from objects, and can be a factor of 5-8x faster to transform for most languages, compared to JSON.

All of this gives us an amazing performance benefit meanwhile minimizing the data that needs to be transported, which is GREAT on subpar network connections.

Performance-wise, gRPC is amazing, between some of our microservices, we are seeing a sub 5ms delivery time of messages.

How did gRPC come to be?

Google has been known to share some of its greater inventions and tools they use inside their own Datacenters. One of the first great ones that came out, was the Protobuf specification, that allows you to create backward compatible, super compact and efficient, ultra-fast serializable messages. Protobuf have been out for several years and are used just about everywhere, because it solves a critical need of having efficient and compact data transfer, meanwhile supporting backward compatible messages.

Internally, Google uses a framework called Stubby, which essentially is what became gRPC. Since stubby is baked into all Google services and is heavily tied to its infrastructure, Google created a new framework called gRPC and made it open source.

This framework has been graciously adopted by the general programming community and is finding its way into most microservice architectures because it massively outperforms the REST API that some microservice systems are using.

Is gRPC only for microservices?

NO!

It is a valid choice in almost all cases where you need high performance or super data-efficient communication between two applications.

It is especially great in these use cases:

• Internal microservice communication
• Mobile app communication
• On-prem applications
• Monolith to monolith communication
• Any software to software communication
• Even a web app on the client-side is supported.

What languages are supported?

C++, Java (+ Android), Objective-C ( iOS), Python, Ruby, Go, C#, Node.js, and others are coming!

Well thats great! How do I get started?

Go to https://www.grpc.io !

Should I truly use it for everything?

Well no, it depends of course, it just makes a good headline. But gRPC should be seriously considered in every situation where you need direct communication between services.

That is a lot of other patterns, in other communication scenarios where gRPC might not make sense, like message queues, although implementation of efficient dispatching of messages has been seen with RabbitMQ using gRPC as a transport layer.

The post Heres why you should use gRPC for everything appeared first on André Snede.