Introduction to gRPC Service

Objectives
◆ Learn the gRPC theory to understand how gRPC works
◆ Compare gRPC and REST API paradigm
◆ Write your gRPC service definition in .proto files
◆ gRPC services on ASP.NET Core

2
 gRPC - 1
◆ gRPC stands for gRPC Remote Procedure Calls
◆ gRPC is a new and modern framework for building scalable, modern and fast
API.
◆ It is leveraged by many top tech companies such as Google, Square & Netflix
and enables programmers to write micro-services in any language they want
while keeping the ability to easily create communications between these
services.
◆ It relies on Protocol Buffers for the transport mechanism and Service Definition
language.

3
 gRPC - 2
◆ The main benefits of gRPC are:
 Modern, high-performance, lightweight RPC framework.
 Contract-first API development, using Protocol Buffers by default, allowing for language
agnostic implementations.
 Tooling available for many languages to generate strongly-typed servers and clients.
 Supports client, server, and bi-directional streaming calls.
 Reduced network usage with Protobuf binary serialization.

4
 gRPC - 3
◆ The benefits make gRPC ideal for:
 Lightweight microservices where efficiency is critical.
 Polyglot systems where multiple languages are required for development.
 Point-to-point real-time services that need to handle streaming requests or responses.

5
Why gRPC? - 1

6
 Why gRPC? - 2
◆ Works across languages and platforms

C#, C++, Dart, Go, Java, Kotlin, Node, Objective-C, PHP, Python, Ruby
7
 Why gRPC? - 3
◆ Works across languages and platforms (contd.)

8
 Protocol Buffers vs. JSON - 1
◆ Protocol buffers, also known as Protobuf, is a protocol that Google developed
internally to enable serialization and deserialization of structured data between
different services.
◆ Google’s design goal was to create a better method than XML to make systems
communicate with each other over a wire or for the storage of data.
◆ Since its development, Google has made Protobuf under an open source
license.
◆ It also provides out of the box support in the most common languages,
including Python, Java, Objective-C, C# and others via Google’s new proto3
language version.

9
 Protocol Buffers vs. JSON - 2
◆ JSON, or JavaScript Object Notation, is a minimal, readable format also used
to structure data.
◆ It is also an alternative to XML and is mainly used as a way of transmitting data
between a server and web application.
◆ JSON uses human-readable way as a way of transmitting data objects made
up of attribute-value pairs and array data types (or another type of serializable
value).
◆ JSON was derived from JavaScript, but since last year multiple programming
languages include code to generate and parse JSON-format data.

10
 Protocol Buffers vs. JSON - 3
◆ Parsing JSON is actually CPU intensive (because the format is human readable)
◆ Parsing Protocol Buffers (binary format) is less CPU intensive because it’s closer to
how a machine represents data
◆ By using gRPC, the use of Protocol Buffers means faster and more efficient
communication, friendly with mobile devices and have a slower CPU.

◆ gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing
structured data (although it can be used with other data formats such as JSON).
11
 Protocol Buffers role in gRPC
◆ Protocol Buffers is used to define the
 Messages (data, Request and
Response)
 Service (Service name and RPC
endpoints)

12
 Protocol Buffer versions
◆ While protocol buffers have been available to open source users for some time,
most examples use protocol buffers version 3 (proto3), which has a slightly
simplified syntax, some useful new features, and supports more languages.
◆ Proto3 is currently available in Java, C++, Dart, Python, Objective-C, C#, a lite-
runtime (Android Java), Ruby, and JavaScript from the protocol buffers GitHub
repo.
◆ In general, while you can use proto2 (the current default protocol buffers
version), we recommend that you use proto3 with gRPC as it lets you use the
full range of gRPC-supported languages, as well as avoiding compatibility
issues with proto2 clients talking to proto3 servers and vice versa.

13
 gRPC Core Concepts
◆ Service definition
◆ Using the API
◆ Synchronous vs. asynchronous

14
 gRPC Architecture
◆ The rough architecture of gRPC. It's more or less the same as regular RPC
◆ gRPC clients and servers can run and talk to each other in a variety of
environments

15
 gRPC Lifecycle - 1
◆ 4 Types of API in gRPC

16
 gRPC Lifecycle - 2
◆ 4 types of API in gRPC
 Unary RPC - Unary RPCs where the client sends a single request to the server and
gets a single response back, just like a normal function call.
 Server streaming RPC - Server streaming RPCs where the client sends a request to
the server and gets a stream to read a sequence of messages back. The client reads
from the returned stream until there are no more messages. gRPC guarantees
message ordering within an individual RPC call.

17
 gRPC Lifecycle - 3
◆ 4 types of API in gRPC (contd.)
 Client streaming RPC - Client streaming RPCs where the client writes a sequence of
messages and sends them to the server, again using a provided stream. Once the
client has finished writing the messages, it waits for the server to read them and return
its response. Again gRPC guarantees message ordering within an individual RPC call.
 Bidirectional streaming RPC - Bidirectional streaming RPCs where both sides send a
sequence of messages using a read-write stream. The two streams operate
independently, so clients and servers can read and write in whatever order they like: for
example, the server could wait to receive all the client messages before writing its
responses, or it could alternately read a message then write a message, or some other
combination of reads and writes. The order of messages in each stream is preserved.

18
 gRPC Lifecycle - 4
◆ Deadlines/Timeouts
 gRPC allows clients to specify how long they are willing to wait for an RPC to complete
before the RPC is terminated with a DEADLINE_EXCEEDED error. On the server side,
the server can query to see if a particular RPC has timed out, or how much time is left
to complete the RPC.
 Specifying a deadline or timeout is language specific: some language APIs work in
terms of timeouts (durations of time), and some language APIs work in terms of a
deadline (a fixed point in time) and may or may not have a default deadline.

19
 gRPC Lifecycle - 5
◆ RPC termination
 In gRPC, both the client and server make independent and local determinations of the
success of the call, and their conclusions may not match.
 This means that, for example, you could have an RPC that finishes successfully on the
server side (“I have sent all my responses!") but fails on the client side (“The responses
arrived after my deadline!"). It’s also possible for a server to decide to complete before
a client has sent all its requests.
◆ Cancelling an RPC
 Either the client or the server can cancel an RPC at any time. A cancellation terminates
the RPC immediately so that no further work is done.

20
 gRPC Lifecycle - 5
◆ Metadata
 Metadata is information about a particular RPC call (such as authentication details) in
the form of a list of key-value pairs, where the keys are strings and the values are
typically strings, but can be binary data.
 Metadata is opaque to gRPC itself - it lets the client provide information associated with
the call to the server and vice versa.
 Access to metadata is language dependent.

21
 gRPC Lifecycle - 6
◆ Channels
 A gRPC channel provides a connection to a gRPC server on a specified host and port.
It is used when creating a client stub.
 Clients can specify channel arguments to modify gRPC’s default behavior, such as
switching message compression on or off.
 A channel has state, including connected and idle.
 How gRPC deals with closing a channel is language dependent. Some languages also
permit querying channel state.

22
Remote Procedure Calls vs HTTP APIs

23
 HTTP/2 - 1
◆ HTTP 2.0 specification was published as RFC 7540 in May 2015.

24
 HTTP/2 - 2
◆ The HTTP request/response gets broken down into frames.
 The headers frame contains typical HTTP headers information.
 The data frame contains the payload.

25
 HTTP/2 Features - 1
◆ Binary Protocol. HTTP/2 is binary,
instead of textual
 More efficient to parse
 More compact on the wire
 Much less error prone as compared to
textual protocols
◆ Multiplexing
 Allows messages to be interleaved together
on a connection at the same time thus
allowing multiple requests and response
messages to be in flight at the same time

26
 HTTP/2 Features - 2
◆ Header Compression
◆ Avoid Head of Line blocking
◆ Prioritization of Frames
 HTTP/2 splits the communication in frames.
 All frames are sent over a single TCP connection
 Frames are interleaved.
 Frames are Prioritized.
 Frames are flow controlled

27
 HTTP/2 Features - 3
◆ Server Push
 Allows server to push responses proactively into client caches for future use.
 Helps avoid round trip between fetching HTML and linked stylesheets and scripts as
server can start sending these things right away without waiting for client to request
them.

28
 gRPC services on ASP.NET Core - 1
◆ Add gRPC services to an ASP.NET
Core app
 gRPC requires the Grpc.AspNetCore
package.
 Configure gRPC in a .NET app.

29
 gRPC services on ASP.NET Core - 2
◆ gRPC services can be hosted by all built-in ASP.NET Core servers.
 Kestrel
 TestServer
 IIS (IIS requires .NET 5 and Windows 10 Build 20300.1000 or later)
 HTTP.sys (HTTP.sys requires .NET 5 and Windows 10 Build 19529 or later.)

30
 Integration with ASP.NET Core APIs
◆ gRPC services have full access to the ASP.NET Core features such as
Dependency Injection (DI) and Logging.
◆ The service implementation can resolve a logger service from the DI container
via the constructor.

◆ By default, the gRPC service implementation can resolve other DI services with
any lifetime (Singleton, Scoped, or Transient).
31
 GrpcGreeter project files
◆ greet.proto: The Protos/greet.proto file defines the Greeter gRPC and is used
to generate the gRPC server assets.
◆ Services folder: Contains the implementation of the Greeter service.
◆ appSettings.json: Contains configuration data, such as protocol used by
Kestrel.
◆ Program.cs: Contains the entry point for the gRPC service.
◆ Startup.cs: Contains code that configures app behavior.

32
gRPC Service Demo

33
Create a gRPC Service Project

34
 Create EmployeeCRUD.proto
◆ This file contains instructions of Protocol Buffer language. The primary purpose
of this file is to define the structure of a service you wish to create. Structure of
a service includes its methods, method signatures, and types needed by the
service.

35
gRPC Service Configuration

36
 Connection String and Service Collection
◆ appsettings.json

◆ Startup.cs

37
Create EmployeeCRUDService - 1

38
Create EmployeeCRUDService - 2

39
Create EmployeeCRUDService - 3

40
Create EmployeeCRUDService - 4

41
 Create the gRPC Client in .NET
◆ Install-Package Grpc.Net.Client
◆ Install-Package Google.Protobuf
◆ Install-Package Grpc.Tools

42
Add greet.proto to Client Project

43
Client Controller

44
Run Project

45
 Summary
Concepts were introduced:
◆ gRPC Core Concepts

◆ gRPC Architecture

◆ gRPC Lifecycle

◆ Compare gRPC and REST API paradigm

◆ Write your gRPC service definition in .proto files

◆ gRPC services on ASP.NET Core

◆ gRPC Service Demo

46