…well technically we don’t need it, but it has its use cases
I was prepared to write a long-winded post about middleware, in response to a question someone asked me at a Meetup, but I realized I had it wrong — though gRPC can be USED for middleware, the best way to describe it is as an RPC system that can serve as a replacement for the REST architectural style. That argument could be its own can of worms (some say it is legitimate, while others call it apples and oranges), but it is probably the simplest place to start the discussion:
I would be reluctant to suggest that every developer throw their current technology overboard in favor of gRPC and choose a side, though there are already quite a few articles making that claim. My cheap answer to why we might need gRPC (other than fitting my usual title theme) is quite simply that it has been so widely adopted. According to the Wikipedia page: A number of different organizations have adopted gRPC, such as Uber, Square, Netflix, IBM, CoreOS, Docker, CockroachDB, Cisco, Juniper Networks, Spotify, Zalando and Dropbox.
A pretty succinct article can be found here, laying out a quick overview of how gRPC uses lightweight messages, performs 5–8 times faster than REST/JSON, and features built-in communication. Before turning this into an aggregate of every other article I can find, let me just describe how this generally works:
You define a service in a protocol buffer file…the example Google uses in its documentation is rectangle attributes for some reason. Depending on the programming language, you generate some language-specific files using the proto compiler. Now you have files you can work with, including a stub (an RPC concept). From here you can create a client and server.
Okay, so here it is. This is just their canned Python example. You can download it right off their GitHub and it can be found in a folder called examples. Does it work out of the box? Data point of Evan, but absolutely not.
When you write the implementation yourself, you can mix-and-match. You can write a server in a variety of languages and then a client in a variety of languages. The point? If you make a server, people can write custom clients to talk to it in a language of their choice.
I had a whole example in mind. I was going to write a service in corgi.proto, which was going to have corgi weight and corgi length…it was going to use C++ and bidirectional streaming. I didn’t get there, so I decided to just go with the out-of-the-box examples, then that didn’t work either, so in the time I was waiting for C++ dependencies I worked through a bunch of forums until I could get their canned Python example to work. So yes, there it is. The server is at the top, and the client is at the bottom.
We can show you some sweet, sweet code.
This is Python, which I’m not super familiar with, but let’s proceed.
helloworld_pb2_grpc are two of the aforementioned files created off of a protocol buffer.
insecure_channel denotes the absence of SSL/TLS, and this is an asynchronous call (yes, there is an entire section on authentication. That part is fairly straightforward, at least on the client side). It comes right with the free open source gRPC/Python documentation, which is a great starting point. You will see there are a few options…you can have the client and server make a single request/reply, or you can use bidirectional streaming, or you can do something like this.
And yeah. There you have it. Client and server.
Whew. Okay. Now things can get interesting.
This is a viral article (well, “viral” is a term I use kind of loosely) advocating for gRPC — you can read some varying opinions in the comments. Here is an interesting one.
Sorry, Arun, RPCs are an archaic technology that I used back in the 70s when it was all we had. Software engineering has come a long way since then.We've learned to avoid tight coupling of components for many compelling reasons. It is a fundamental principle of microservice architecture. It is painful watching developers making the same mistakes again for the same old reasons.JSON didn't exist when Roy Fielding wrote his dissertation on REST, but it is a useful "self-defining" message syntax. Protocol buffers are anything but self-defining and require a complex system for distributed schema management to work at all. That may be justifiable when data compression is the overriding concern, but it makes loosely-coupled microservices impossible to implement.A properly designed RESTful solution is a far better match for the implementation of a microservice architecture.https://medium.com/nerd-for-tech/microservice-architecture-622e4148f1--Dick Dowdell https://dick-dowdell.medium.com/?source=responses-----60737b23e79e----4----------------------------
My opinion? I really don’t know, but it’s a fascinating discussion.
gRPC is useful in the industry now, and google protocol buffers are even more popular. It’s fast. There are benefits to having the same set of protocol buffer files produce different language bindings in seconds. It could be the future. But will we still need to use REST APIs in the meantime?
Of course, for a variety of things. This is the typical inertia trade-off so prevalent in tech, though at the very least the comment above suggests that there may be other reasons we may want to think twice about this.
A good project would be building out an entire end-to-end system with gRPC. Because of its nature, this could also double as a neat language-learning exercise. Python? Sure. C++ client? Why not?
I hope to continue on with a second post addressing middleware, maybe with ZeroMQ’s canned example.
Here is an article on something called Tiger that many people mercilessly dumped on for its clickbait title, “REST is dying, get rid of it.” What I find interesting here is some have suggested GRPC as a better version of TIGER.
What does it stand for? No idea.
One day I will invent my own project called CORGI.