gRPC is a modern high performance RPC (Remote Procedure Call) framework that can run in any environment. gRPC is based on HTTP/2, Protocol Buffers and other modern standard-based technologies. Together with excellent tooling, it helps you create high throughput, low latency, real-time services.
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
gRPC on .NET Core - NDC Oslo 2020
1.
2. gRPC is…
• Popular open source RPC framework
• Largest RPC mindshare
• Cloud Native Computing Foundation project
• gRPC stands for gRPC Remote Procedure Calls
• Built with modern technologies
• HTTP/2
• Protocol Buffers
• Designed for modern apps
• High performance
• Platform independent
+ =
3. Protobuf (aka Protocol Buffers)
• IDL (interface definition language)
Describe once and generate interfaces for
any language
• Service model
Service method and structure of the
request and the response
• Wire format
Binary format for network transmission
syntax = "proto3";
message SubscribeRequest {
string topic = 1;
}
message Event {
int32 id = 1;
string details = 2;
}
service Topics {
rpc Subscribe(SubscribeRequest)
returns (stream Event);
}
5052 4920 2a20 4854 5450 2f32
0d0a 534d 0d0a 0d0a 0000 0004
0000 0000 0401 0000 0000 0000
4. Remote Procedure Calls vs HTTP APIs
• Contract first (proto file) • Content first (URLs, HTTP method, JSON)
• Contract is designed for humans
• Hides remoting complexity
• Content is designed for humans
• Emphasises HTTP
HTTP APIsRemote Procedure Calls
Performance
Developer productivity
Widest audience
Ease of getting started
5. Demo!
• Create gRPC service using template
• Create gRPC client
• Call service
6. Grpc.Core
Going deeper: gRPC on .NET Core
Grpc.Core
Grpc.Core.Api
Grpc.AspNetCore Grpc.Net.Client
• HTTP/2 via Kestrel
• Integrates with ASP.NET
• HTTP/2 via HttpClient
• DelegatingHandler
11. Key features - Streaming
• gRPC uses HTTP/2 to enable streaming
12. gRPC-Web + Blazor Demo
• Add gRPC-Web on the server
• Call gRPC service from Blazor WebAssembly
13. gRPC for .NET 5
• gRPC-Web
• HttpSys support
• Keep alive
• Inter-process communication
• Performance
• HPack header compression
• Server allocations decreased by 75%
• Server RPS increased by 25%
• Client RPS increased by 300% (!!!)
• Span<T> support in Protobuf serializer
14. Try gRPC on .NET Core today!
• gRPC docs – https://docs.microsoft.com/aspnet/core/grpc
• gRPC with ASP.NET Core authentication
• Logging and diagnostics
• HttpClientFactory integration
• gRPC for WCF Developers
https://docs.microsoft.com/dotnet/architecture
Done! Questions?
Hinweis der Redaktion
-Me
-Developer on ASP.NET team
-Working on gRPC since beginning of the year
-Launched last month with 3.0
-There are alternative RPC frameworks, e.g. Thrift
-Developer community is unifying behind gRPC
-gRPC is run by CNCF. Microsoft contributing to CNCF
-Does not stand for Google RPC
-gRPC is not new, open sourced in 2015
-Union of two technologies, HTTP2 and Protocol Buffers
-Designed for modern apps, particularly microservices
Protocol Buffers serves three purposes:
-Language independent definition of Protobuf messages. Written in proto file that can be shared between apps
-Definition of services for use on server and client
-Binary format of messages. Small and fast, but not human readable
gRPC is an opination contract-first RPC framework
HTTP APIs focus on the shape and content of HTTP (contract optional)
proto files are designed for humans to write and read. Content is binary
HTTP APIs are the opposite: content is human readable. Optional schema is rather verbose
gRPC methods are designed to hide complexity of remoting
Call them like you would a method, no creating HTTP messages or JSON content
Create gRPC project in VS
Talk through proto – messages, service, this is the contract
Talk through service – generated file, F12, location, ILogger (DI)
Launch. Browse to server
Create client project – add packages, add proto
Look at service references
Update Program.cs
Lets go a bit deeper into what has been added in .NET Core
Grpc.Core is the existing C# gRPC stack. First released 2015
.NET wrapper of a native implementation of gRPC and http2
Slow, large native dependencies
New: Grpc.AspNetCore and Grpc.Net.Client
- GrpcAspNetCore: uses Kestrel’s HTTP/2 support, integrates with ASP.NET
- The new client uses HttpClient internally. Can use Delegating Handler outgoing middleware
One of our goals has been portablity between Grpc.Core and grpc on .net core
Split common API into its own package and reuse
End result: existing gRPC services can use newer server and client
Grpc.Core is not going away. Has features that new bits don’t, supports .NET Framework
A key benefit of gRPC vs REST is small size of requests
-HTTP/2 is binary compared to text based HTTP1
-HTTP/2 supports header compression. Commonly occurring headers, e.g. content-type, are compressed to a few bits per request
-Protobuf is significantly smaller than JSON
JSON is a self describing format – characters are included to differentiate objects/arrays/strings/numbers
Protobuf requires the proto file to make sense of content
Simple comparison between JSON and Protobuf
Protobuf is 30% the size of JSON
Difference reduces to 50% with gzip
HTTP/2 multiplexing makes more efficient use of TCP connections
Multiplexing improves on HTTP1.1 pipelining
-Pipelining requires the order of requests and responses match
-A large image or slow API call may prevent faster requests from completing
HTTP/3 should improve this situation even more.
Code generation is at the core of gRPC
Code generation is driving by Protocol Buffer IDL
Example
-Simple server streaming call
-csproj references proto file in ProtoBuf item
-Grpc.Tools has targets to generate .NET types at design time
-Server is a base type that requires implementation
-Client is strongly typed, created with channel that specifies the server location
Proto files can be shared between servers, and languages.
gRPC is supported in every language
-Common set of interop tests
-gRPC on .NET Core is continuously tested against other implementations
HTTP/2 has excellent streaming support
gRPC uses HTTP/2 streaming to enable message streaming
Unary. Like REST. Single request, single reply
Server streaming is initiated with a request, returns a stream of responses. Example, subscribing to updates.
Client streaming is the opposite: stream requests, finish with response. Example: uploading data
Bi directional stream is streaming in both direction. Example: chat room
gRPC streaming is a really easy way to create realtime services.
I’m going to demo gRPC in the browser. gRPC traditionally can’t run in the browser but this feature makes it very simple in .NET
Run project. Demo weather page
Look at REST request. Note size
Enable gRPC-Web on the server
Package ref
UseGrpcWeb
Call gRPC
Update csproj
Update Program.cs
Inject channel
Update call code
Add ToDateTime
Run project. Note new size
gRPC-Web. Available now
HttpSys is a server that is part of Windows. Supported in 5.0, although it will require you to run on a Windows version that includes an updated HttpSys
Keep alive pings help keep connections alive when they are in use, and close them when one side doesn’t respond
Keep long lived, inactive streams alive
Better first request performance by keeping the connection open
Inter-process communication is gRPC calls between apps on the same machine.
Can be done today using TCP sockets, but we want to support named pipes and unix domain sockets
A big focus is performance.
Graph shows requests per second with different gRPC servers. The jump in the .NET Core results in this graph is from moving from .NET 3.1 to .NET 5
Added Hpacker header compression to Kestrel. Commonly reaccuring headers are compressed to a fraction of there size
Pool and reuse HTTP/2 streams in Kestrel, reducing allocations by 75%
Increased HTTP/2 server RPS by 25%
Identified lock contention in the client, increasing RPS by 300%!
Finally, we’re working with the Protobuf project to support Span<T> in their serializer
gRPC for .NET Core is on NuGet today.
A template ships with .NET Core 3.1
For more information, the best place to go is the docs.
There is lots there that I haven’t discussed today
We’ve worked with the community to write a book on moving WCF services to gRPC
That’s it! Thank you for your time. Questions