Our Blog

Your source for Technical Ramblings in the world of Software Delivery and Digital Transformation

Feb 01

Here is a write up of the GRPC lightning talk I gave at Scala Manchester Meetup, remember to sign up to the group if you are in the Manchester area and pop along to our next meetup. If you would perfer to listen to the talk you can check it out on Youtube below.

If you would prefer to read through the content let's get started.

gPRC - What is it?

gRPC is a transport mechanism for request/response and (non-persistent) streaming use cases. It is a schema-first RPC framework, where the protocol is declared in a protobuf IDL descriptor and requests / responses will be streamed over an HTTP/2 connection. In this short blog we will go through some of the concepts and show a working example, we will make some comparisons to older tech and loosly evaluate the Pro's & Con's.

The Pro's

  • Schema-first design for Messages and Services
  • Protobuf allows for compatible schema evolution
  • Efficient use of HTTP/2, allows multiplexing of data streams
  • Language agnostic providing interoperability
  • Streaming is a first-class citizen

The Con's

  • Increased Develpoment Effort
  • Tooling still improving
  • Generated code
  • Synchronous Communication

So GRPC can provide us a typed, schema driven way of communicating between services, as with most good things there are some caveats. It's still a relavivly new tech that is being adopted and trialed by the community and well, its more upfront dev effort than throwing some json at an endpoint. But given that its still worth exploring...

gRPC all the things!!!

This sounds great I hear you say, lets gRPC all the things!! However consider the following points before jumping straight into the implementation.

  • Is there is a Well definied connection between internal services?
  • Do you reqire a Structured way to serve data to a front-end?
  • Is there a need to encapusulate a specialist or legacy bit of code in a different language?

Old News

But this is just old news right, CORBA tried to solve this problem years ago! In someways yes, the CORBA implemenation was trying to solve some of the same fundamental issues. However in my opinion it had two major problems, CORBA provided the ability to pass Object References, which massively coupled the two services. The protocal used to communicate was also a bit of a problem and caused a whole load of issues in one of the projects I worked on, the GIOP/IIOP, TCP based protocol added another layer of complexity. So, in my opinon CORBA was a good idea with an overly complex impliementation.

Clean me up

Is this not just SOAP?

Although SOAP allows you to define a structured message for communication between Client / Server, as well as the functionality generate implementations in various langugaes, there is no ability to evolve the definition without creating new routes or wsdl versions. This made API evolution painful and often lead to WSDL definition being out of date comapired to the actual API. The Transport mechanism is also built upon TCP/IP which provides an overhead when communicating between services, gRPC in comparison utilises the HTTP/2 standard allowing for long running connections to remain open.

Get on the BUS

Whilst gRPC is built on an efficient non-blocking implementation, gRPC is still synchronous in the sense that it requires both client and server to be available at the same time.

Dependant on the problem you are trying to solve, a distributed message bus such as Kafka may be a better solution, you can still utilise Protobuf and have structured messages. Whilst getting the advantage of decoupled integration but at the price of higher latency.

Magical Unicorn Example.

Imagine you have a magical highly performant function that is embedded in the DotNet Framework and you need to expose that functionality to a set of services in your micro-service architecture.

** gRPC to the rescue!!! **

             +---------+                  +--------+
+-----+      |         |                  |        |
|  C  |      |  Scala  |   gRPC (HTTP/2)  | Dotnet |
|  O  |      |  (jvm)  +------------------+  Core  |
|  N  |      |         |                  |        |
|  S  +------>         |   HelloRequest   |        |
|  O  |      |         +------------------>        |
|  L  |      |         |                  |        |
|  E  |      |         |   HelloResponse  |        |
+-----+      |         <------------------+        |
             +---------+                  +--------+

The above example shows two different worlds communicating as if it were a simple method call, most of the heavy lifting can be done in build process and with editor plugins that will become available as popularity increases. It's an exciting concept that seems to be well implemented and easy to use.

Try it out for yourself.

Find the working example on Github

References:

  • Lightbend docs on Akka gRPC : https://developer.lightbend.com/docs/akka-grpc/current
  • Google API design Patterns : https://cloud.google.com/apis/design/design_patterns
  • gRPC : https://grpc.io/

I'd love to hear some of the use cases for gRPC, comment below and we can chat...

until next time

-Alex.