SlideShare a Scribd company logo
gRPC
RPC rebirth?
About me
◦ Luís Barbosa
◦ bymyslf@GitHub
HTTP API’s in the microservices world
HTTP API Paradigms
◦ RPC (gRPC)
◦ REST (HTTP + JSON)
◦ “Query language” (GraphQL)
HTTP API Paradigms
◦ RPC (gRPC)
◦ REST (HTTP + JSON)
◦ “Query language” (GraphQL)
[API Paradigms] - RPC vs REST
◦ RPC
▫ exposes operations as a method for acting upon data
◦ REST
▫ exposes data as resources to be acted upon
It’s a matter of context/use case!
[API Paradigm] - RPC
◦ Origination
◦ Marshaling
◦ Broadcast
◦ Reception
◦ Unmarshaling
◦ Response
[API Paradigm] - REST
◦ Client-Server
◦ Stateless
◦ Cacheable
◦ Layered
◦ Code on demand (optional)
◦ Uniform Interface
▫ Identification of resources
▫ Manipulation of resources
▫ Self-descriptive messages
▫ Hypermedia as the engine of application state
(HATEOAS)
[API Paradigms] - Some use cases
◦ RPC
▫ Truly microscopic services
▫ Remote system execute/events/commands
▫ Inside bounded context or organization
◦ REST
▫ Public/Client facing API
▫ Manipulating the domain
▫ Crosses bounded context/organization
What is gRPC?
“
A high performance, open-source
universal RPC framework
'g' stands for something different every gRPC release
◦ 1.0 'g' stands for 'gRPC'
◦ 1.1 'g' stands for 'good'
◦ 1.2 'g' stands for 'green'
◦ 1.3 'g' stands for 'gentle'
◦ 1.4 'g' stands for 'gregarious'
◦ 1.6 'g' stands for 'garcia'
◦ 1.7 'g' stands for 'gambit'
◦ 1.8 'g' stands for 'generous'
◦ 1.9 'g' stands for 'glossy'
◦ 1.10 'g' stands for 'glamorous'
◦ 1.11 'g' stands for 'gorgeous'
◦ 1.12 'g' stands for 'glorious'
◦ 1.13 'g' stands for 'gloriosa'
◦ 1.14 'g' stands for 'gladiolus'
◦ 1.15 'g' stands for 'glider'
◦ 1.16 'g' stands for 'gao'
Building a
Cache Service
IDL
Interface Definition Language
[IDL] - service.proto
[IDL] - 1 file 10 languages
◦ C++
◦ Java (includes Android)
◦ Python
◦ Go
◦ Ruby
◦ C#
◦ Node.js
◦ Objective-C
◦ PHP
◦ Dart (Beta)
◦ Web (Beta)
Server
[Server] - Server.cs
Client
[Client] - Client.cs
How does this work in production?
gRPC on the wire
◦ HTTP/2
◦ Protocol Buffers serialization by default
◦ Clients open one long-lived connection to the server
▫ A new HTTP/2 stream for each call
▫ Allows simultaneous in-flight calls
◦ Allows bidirectional streaming
▫ Server-side streaming
▫ Client-side streaming
gRPC implementations
◦ 4 high-performance event-loop driven implementations
◦ C
▫ C#, Ruby, Python, node.js, Objective-C, C++ (C core
bindings)
▫ PHP (PECL extension)
◦ Java
◦ Go
◦ Dart (beta)
Service Implementation
[Service] - CacheService.cs
Error Handling
[Service] - Error handling
[Service] - Error handling types
◦ Client
◦ Server
◦ Both
◦ Never generated by the library
Error handling - examples
New requirement
Correlation ID
Metadata
gRPC “headers”
[Metadata] - Client.cs
[Metadata] - Server.cs
[Metadata] - ServerCallContextExtensions.cs
Interceptors
gRPC “middleware”
[Interceptors] - Types
◦ Client-side
◦ Server-side
◦ Inherit from Interceptor base class
[Interceptors] - CorrelationIdInterceptor.cs
[Interceptors] - Client.cs
[Interceptors] - Server.cs
Secure Transport
[Secure] - gRPC Authentication
◦ SSL/TLS
▫ Authenticate server
▫ Encrypt data exchange client-server
◦ Token-based
▫ Google credentials (pluggable)
◦ Authentication API
▫ Channel credentials
▫ Call credentials
[Secure] - Credentials.cs
[Secure] - Server.cs
[Secure] - Client.cs
New Feature
Get by key pattern
[GetByKeyPattern] - service.proto
Out of Memory!!!
Streaming
[Streaming] - service.proto
[Streaming] - CacheServiceImpl.cs
[Streaming] - Client.cs
Advanced Feature
Support JSON
[JSON] - Serializer.cs
[JSON] - Messages.cs
[JSON] - Descriptors.cs
[JSON] - Server.cs
It’s done! We did it!
And the not so good parts...
The not so good parts
◦ Load Balancing
◦ Limited error handling
◦ Support for browser js still beta
◦ Breaking API changes
◦ Poor documentation for some languages
◦ No standardization across languages
Show me the code
@GitHub gRPC-Cache-Service
Q&A
“ Thank you

More Related Content

gRPC - RPC rebirth?