Heres why you should use gRPC for everything

gRPC makes calling services on other applications or servers very easy. It is blazingly fast, and uses protocol buffers to deliver very compact messages!

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.

You may also like...

15 Responses

  1. Phil Motuzko says:

    The biggest show stopper for me is a lack of support for Decimal (which is mandatory for the financial systems) and DateTime types from .Net. otherwise, highly recommend. Especially, when the WCF is dying.

    • We use both DateTime and DateTimeOffset in our code. We just wrap the data in a DTO.

      I suppose you could do the same with Decimal. You should separate the messages from your domain model anyways.

      Also I can see that this is actually supported by protobuf-net, so maybe there is a way?
      https://stackoverflow.com/questions/371604/whats-the-best-way-to-represent-system-decimal-in-protocol-buffers

    • Heisthefox says:

      If you think protobobs are unable to transport floating point data types, then you do not understand data types while enough to be writing software for financial institutions. I think I know understand why financial day is constantly getting compromised. Having use protobots for many many years, there are multiple ways to transport all types of data, Google uses protobots extensively and I guarantee you they perform some financial transactions.

      • That says:

        Is it protobobs, protobobs, or protobuf?

        • Alexander Yuryshev says:

          Protoirony, I suppose. Protosarcasm maybe.
          From experience of one protohappy user

      • Francois says:

        You’re right. OP shouldn’t be working in financial systems because he clearly doesn’t understand protobot or protobob. I think he only knows protojeff and we all know how unreliable jeff is.

    • Nils says:

      IEEE floating point is only imprecise when calculated with. Any given floating point number can be safely converted to/from a string representation, which is what you normally see (in code, println, etc).
      So if you have a native decimal type, it is safe to convert to/from floating point, with no loss. When in FP representation, it’s not exact, but that’s irrelevant if all you do is convert it back to native decimal the same way.
      HTH

      • Evade Flow says:

        One mark against gRPC is that its asynchronous API is a train wreck of complexity. And once you get past Hello World-type examples, you *need* async. I think gRPC will fall out of favor for this reason. Anybody who has used Boost.Asio will chafe at gRPC’s needlessly Byzantine async interface.

    • Andrew says:

      If you look at the clojure android framework they have a BigDecimal and a BigInteger, somewhat similar to the Java versions, that have quite complete test coverage. They are eclipse license as well in case you need to copy them.

  2. Manos says:

    Well if you have other options regarding rpc frameworks I would go for the other option. grpc core is full of obscure bugs, horrible API and absolutely crappy documentation when it comes for the internals of the framework.

  3. Vasiliy says:

    I think grpc very inconvenient for web applications, no native support in web browsers and very noisy code generators that force to use some proxy for back compatibility http 1.1.

  4. Vasiliy Mazhekin says:

    Rpc is the old mechanism that appears a long time ago, but not convenient for web development thought unstable working and complexity, so the web services and REST have most wide using.

  5. codematrix says:

    Ah, I remember the days of .NET Remoting in early 2000. gRPC sounds very interesting. What would be great if Microsoft can create a few things.

    1) Middleware that can take REST requests in gPRC format, translate request/response objects into protobuf. This way you can still keep exiting APIs without change but benefit from the performance hit.

    2) Create the client library that can consume your exiting API as though they are gPRC.

Leave a Reply

Your email address will not be published. Required fields are marked *