gRPC
How do we make computers talk to eachother? More specifically, how do we make apps that talk to each other and build rest APIS . You’re tredding on a right path if you’ve thought it was either REST or rPCs.
Most of the web APIs these days are a combination of HTTP + JSON. It’s more of about how we structure the way our APIs talk to each other. Wikipedia defines REST as “a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the Internet.” HTTP/REST are all great. A few quick-notes:
The +1 part
- REST is easy to understand.
- There’s a lot of Web infrastructure that’s already built on top of HTTP.
- There a lot of tools for testing and modification.
- There’s (relatively)loose coupling between the client and server thus making changes easy.
- High Quality http implementations in (almost)every-language.
In the same world, there are people who are vexed with REST and would call the APIS written using that principles to be the WORST of all the other API’s that exist.
If I never write another REST client in my life, I’ll die a happy man. - Alan Shreve, Creator of ngrok
Although it has taken on many different forms. RPC-based APIs are better for procedure or commands, while REST is more about modeling the data and state. Here’s why
Not so +1
- There’s no formal(machine-readable) definition for REST viz., API contract. This makes us forcefully involve expensive human effort to write clients in languages that are missing a client.
- Streaming is almost(almost(almost(almost(almost)))) impossible. This is just uni-directional.(NOOO Question of bi-directional streaming)
- Hard to get many resources in a single request.
- Internal services aren’t RESTful anyway.
- Operations are hard to program.
GRPC is that smart eh?!
This is how the gRPC documentation describe itself.
“ a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. “
Basically, there are service definitions(request/response formats) written as protobuf unlike the ones we generally write in the REST world. The interesting part is that we can run the protobuf through a compiler.
Yes, there’s a compiler for gRPC and so we can run the protobuf through the gRPC compiler and we can have our client libraries generated in language of our choice.(language from amongst those officially supported by the grPC). See an example here
It may feel like the WSDL all over again.
Yes it is, and no it’s not.
Actually, machine readable API contracts are a great idea. The fact that this is not present in the REST world makes the REST world less beautiful.
As mentioned earlier, just like the client stubs we can also generate server stubs in the supported languages using the compiler.
Wait, we didnot talk about GRPC yet!
GRPC is a high-performance open source universal RPC framework. On the wire,
- built on top of HTTP/2(transport)
- protobuf serialization
- Clients open one long-lived connection to a grpc servert(Basically HTTP/2 allows to take one single physical stream and multiplex them over to multiple logical streams allowing simultanoues inflight RPC calls ie., every rPC request a HTTP request and vice-versa)
- There’s streaming too!
Implementacion
There are three high-performance event loop drive implementations in
So, where did it all start?
gRPC originated in Google. Google internally had a system called stubby for google services only. Over time with several co-ordinated efforts and contributions from many people, gRPC took a birth in the opensource world.
It’s now F\OSS.