REST is not the Best for Micro-Services GRPC and Docker makes a compelling case

原文：https://hackernoon.com/rest-in-peace-grpc-for-micro-service-and-grpc-for-the-web-a-how-to-908cc05e1083

https://stackoverflow.com/questions/43682366/how-is-grpc-different-from-rest

------------------------------------------------------

REST is not the Best for Micro-Services GRPC and Docker makes a compelling case

June 7th 2017

For quite a long time, when Service Oriented Architecture (SOA) and WebService were the talk of the tech town, most of the software systems were built using SOAP and related WSDL technology. I was involved in multiple projects built using SOAP technology. I started first dabbling with REST when faced with the need to create a quick prototype northbound/external interface for a system.

I, like many others, fell in love with REST immediately ;more so after reading more about it, in the jewel of a paper (Architectural Styles and the Design of Network-based Software Architectures,) by Roy Fielding -principal author of HTTP protocol and consequently founder of the World Wide Web based on the internet. Soon along came JSON; and REST and JSON quickly replaced the cumbersome inefficient SOAP and associated WSDL in building out Service Oriented Architectures.

Programs or other components could now easily talk to each other efficiently through firewalls over HTTP; just like SOAP but much more efficiently. More so the versioning in WSDL, or the lack of it, and the problems it causes when modifying, or slightly extending a published interface, all but vanished. Though a lot of Web Services still uses SOAP, most new development and especially software systems became internally composed of REST based services.

RESTful architecture is what the world wide web is based on. It is as relevant to that context now, as it was when HTTP was designed. But for composing software systems by modern software development teams, there are better technologies that are available now.

Protobuffer was the technology Google was using for long, along with GRPC , in its software ecosystem — one of the largest micro service ecosystems in the world. Google open sourced GRPC in 2015.

Though few companies will operate at this scale, this is a technology that is very relevant in most enterprise SW; with globally distributed teams, working over different time-zones, languages and cultures. A strongly typed and versioned interface helps a lot in the SW development in such companies and generally even across multiple teams.

While technologies like Protobuffer and GRPC are unambiguous in their implementations, the term micro-service reminds me loosely of the SOA acronym. Other than people very close to SW development, to many this terms is confusing. However this is not just a hype promoted by commercial SW vendors. Many companies like Netflix have started using Micro Servicesas a way to compose SW systems successfully.

What makes a Service in SOA a Microservice ? Maybe to get a context of what a micro-service is, you may need to know a little about the Why Micro-Service part

Basically, a microservice does fewer things, a lot of excellent articles are written regarding micro-services, but more than what it is, is what it frees; developers are not constrained to add features to the existing services blowing up the best thought of services into a behemoth over time. Developers have more control and flexibility of the system they are building.

The advent and wide adoption of easy to use container technology like Docker has a lot to do with the success of microservice. Usually microservice systems are implemented as a set of Docker containers.The immutable Docker layers concept, and easy composition via DockerFile, has really taken the OpenClosedPrinciple from a source code structuring practice that few knew and followed, to wide adoption by applying the principle to the executable, the binary level. A released Docker image is immutable, it is closed for all modifications. Having a good versioning strategy for the images ensures that, what is released, stays forever immutable and extension can be released as a different image, with a different version.

Here are some of the top reasons which have attracted me to use GRPC and Protobuffer technology in micro-services.

1. Static Typed & Versioned Interface between Components

Have you ever missed while working in REST, the strongly typed interfaces of distributed technology that had come and gone over the years COM , CORBA IDL’s and SOAP’s WSDL ? Neither have I; barely noticed, maybe a bit glad of not needing to do or deal with the monstrosity of WSDL’s code generation and allied; at least not until the lack of type deficiency began to show on SW development and integration in a multi-team, multi-component system. Here the lack of a strong versioned typed interface gave to all sorts of coding horrors; miscommunication and mistrust between disparate distributed teams.

2. Efficiency & Stability

REST and JSON were way more efficient than the XML heavy SOAP payloads that get passed around between Web Services. GRPC uses Protobuffer for binary serialization of messages, which gives a lot more efficiency when compared to textual JSON used by REST. Also, GRPC works on HTTP/2.0 protocol, unlike most REST libraries which implicitly use the ubiquitous HTTP /1.1. HTTP/2.0 is multiplexed, has header compression and is way more efficient than HTTP/1.1. Till I started using and reading about GRPC, I did not even knew about HTTP/2 and the efficiency it offered.

3. Polygot Programming

GRPC and Protobuffer are available in popular languages like C++, Java, Node.js (Typescript), Go among others. This gives tremendous flexibility in building a system. For example, for some computer vision based tasks that require CPU, GPU resources, you can power-up a C++ -GRPC based micro-service, that interfaces with a Go based micro-service and a TypeScript based micro-service. In practice, composing a software system with the flexibility to use the right programming language is a pretty good advantage.

4. Request-Response Streaming, message-queue

There are many other reasons too. One example that I find pretty intriguing and testing out in production is the streaming part; you can either have the request streamed, the response streamed, or both request and responses streamed over. This is making the message queue implementations or Akka based remote actors obsolete, for many of the asynchronous message based communication that happens in a software system.

5. Almost Serverless

The other being the fact that the GRPC implementation is as server-less as you can get, without going full serverless. That is you don’t need Java’s Jetty/Jersey/Tomcat/Jboss (in the increasing order of server-side thickness), Scala’s Spray (and accompanying DSL monstrosity), C++ nothing/G-SOAP ? or any other full-fledged server or embedded servers. GRPC server library implementation in most of the languages I have tried seems to be mature and ripe for production. And you barely notice. It is almost like serverless, without having to sell your soul to the ‘server provider’. And the server in it is the efficient, multiplexed HTTP/2 based server.

However this same use of HTTP/2 is one sticking problem in adoption. This means that unlike REST, you cannot just type the GRPC API in browser view and expect it to work. So this integration with front-end is usually a problem that sticks out. There are options to work around that, one having a backend for front end component, to orchestrate among the multiple back-end micro-services and expose a REST API for the GUI layer. The other is using a proxy to proxy the HTTP/2 based GRPC to HTTP/1.1 via grpc-web. I have written a how-to for the latter part. You can read about this here.

Update: August 2018

A blog post I found was mirroring the exact same problems regarding the problems of Interface Semantics with REST. Other than experiencing this yourself with time, or reading about it from other peoples experience, it is hard to prove or disprove design decisions.

Our existing systems have traditionally used REST APIs with JSON payloads for communicating synchronously. This choice was made based on the overwhelming maturity, familiarity, and tooling available, but as our cross-continent engineering teams grew, we needed to design a consistent, agreed upon RESTful API. …Eventually, the complications with our REST API led us to search out alternatives https://blog.bugsnag.com/grpc-and-microservices-architecture/