Building Language Agnostic APIs with gRPC - JavaDay Istanbul 2017
Agnostic APIs with gRPC
Java Day İstanbul
6 May 2017
A high performance, open-source universal
Quick Back Story
• Google has been using its own RPC framework
Stubby to communicate millions of micro-services
for over a decade. 10^10 RPC calls per second.
• A uniform and cross-platform RPC allowed
efﬁciency and quick deployment and development.
• However Stubby was tied to Google internals,
therefore they rebuilt it with newer technologies
such as HTTP/2 to extend its usage, and open
source gRPC was born
Why would you want to use
• Quickly build APIs and avoid writing request/response parser
• Use the language you desire interchangeably for client-server
• Avoid on-the-ﬂy parsing by imposing a pre-established schema
and have low latency and highly scalable system
• Use bi-directional streaming instead of classical request-
• Use HTTP/2.0 for having millions of streams over a single-
How does gRPC Work?
• You deﬁne your service in Protocol Buffers format.
• From a .proto ﬁle, server-side and client-side code
are generated for your favourite languages
• You extend the generated code and implement the
required interfaces only and start listening on a port
• In same or another language, you can use the
generated client code to connect to your server,
avoiding writing any boilerplate code.
In short, gRPC allows you to deﬁne your
service, generate boilerplate codes for you and
you only have to write your business logic.
You can decide on the service deﬁnition initially, and let
client and server to be developed independently. You can
also easily upgrade your service deﬁnitions with gRPC.
• IDL: Interface Deﬁnition Language
• Data Model: Request and Response are Structured
• Wire Format: Binary, because computers do not
Protocol Buffers vs JSON
Binary Encoded Text Encoded
Decoding requiredRapidly parseable
Streaming Services in gRPC
• Simple RPC: Request and response
• Server-side streaming RPC: Client makes a request and
then server sends many responses over time until there
are no more.
• Client-side streaming RPC: Client makes many requests
over time, server reads them and sends a single response
at the end.
• Bi-directional streaming RPC: Both client and server
sends each other messages over time and both streams
can be independent.
Language support in gRPC
Principles of gRPC
• Services not Objects, Messages not References
• Coverage & Simplicity
• Free & Open
• Interoperability & Reach
• General Purpose & Performant