9. Blazor on client or server
https://...
DOM
Razor Components
.NET
WebAssembly
https...
DOM
.NET Core
SignalR
Blazor WebAssembly Blazor Server
Razor Components
.NET
.NET Core 3.0May 2020
10. Blazor on client or server
Blazor WebAssembly Blazor Server
.NET Core 3.0May 2020
12. Build your own pizza store UI with Blazor
https://aka.ms/blazorworkshop
13.
14. https://www.telerik.com/blazor-ui
“Telerik UI for Blazor components have been built from the ground-up
to ensure you experience shorter development cycles, quick iterations
and cut time to market”
“DevExpress UI for Blazor ships with 12 UI components (including a
Data Grid, Pivot Grid, Charts and Scheduler) so you can design rich user
experiences for both Blazor server-side and Blazor client-side
platforms.”
https://www.devexpress.com/blazor
“The Syncfusion ASP.NET Core Blazor Components library is the only
suite that you will ever need to build an application, containing over 60
high-performance, lightweight, modular, and responsive UI controls in a
single package.”
https://www.syncfusion.com/blazor-components
20. 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
+ =
21. 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
22. 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
23. Demo!
• Create gRPC service using template
• Create gRPC client
• Call service
24. Grpc.Core
Going deeper: gRPC on .NET Core 3.0
Grpc.Core
Grpc.Core.Api
Grpc.AspNetCore Grpc.Net.Client
• HTTP/2 via Kestrel
• Integrates with ASP.NET
• HTTP/2 via HttpClient
• DelegatingHandler
29. Key features - Streaming
• gRPC uses HTTP/2 to enable streaming
30. Going deeper: gRPC and HTTP/2 requests
POST /SayHello
host: localhost
content-type: application/json
{"name":"world"}
HEADERS frame
DATA frame
HTTP/1.1
HEADERS frame
DATA frame
HTTP/2
POST /greet.Greeter/SayHello
host: localhost
content-type: application/grpc
1: world
31. Going deeper: gRPC and HTTP/2 responses
200 OK
date: Mon, 18 Jul 2020 16:06:00 GMT
server: Kestrel
content-type: application/json
{"message":"Hello world"}
HEADERS frame
DATA frame
HEADERS frame
HTTP/1.1
HEADERS frame
DATA frame
HTTP/2
200 OK
date: Mon, 18 Jul 2020 16:06:00 GMT
server: Kestrel
content-type: application/grpc
1: Hello world
grpc-status: Success
32. Demo!
• Update proto with server streaming call
• Implement on server
• Call from client
33. Disadvantages – Limited browser support
• Browsers have great HTTP/2 support
• Browser JavaScript APIs haven’t caught up
• gRPC-web provides limited support for calling gRPC services
34. Disadvantages - Not human readable
• HTTP/2 and Protobuf are binary
protocols
• Additional tools required to
debug calls
BloomRPC
Today we’re going to show you how .NET can be used to build any type of app. We’re going to start with cloud development and microservices.
<CLICK TO NEXT SLIDE>
-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 3.0
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.
Before demo streaming, lets look at what gRPC sends and receives
HTTP/1.1 request: headers followed by optional body. Text based
In HTTP/2 the request and response are each a stream of frames
This request would be a HEADERS frame followed by DATA frame
A text version of a basic gRPC request.
gRPC still uses HTTP. Not like SOAP, no XML envelope to a single URL
As you would expect headers, in the HEADERS frame
Message in DATA frame
A HTTP API response in HTTP/1.1 is the same:
HTTP headers followed by a response body
The mapping to HTTP/2 is also the same
Now lets look at a gRPC response.
1. Headers are written to a HEADERS frame
2. The response message is written to DATA
3. What is grpc-status? It is sent after the body has started but it is not in the body/DATA frame.
grpc-status is sent in another HEADERS frame. These are called trailing headers, or just trailers.
Why grpc-status and HTTP status? The answer is streaming. Like you can have multiple header frames, you can have multiple data frames, each with there own message.
Headers are sent with the first message returned, we need a status of the overall gRPC call, hence a status in the trailers
Update server proto with new method
Implement method on service
Copy new method to client proto
Call new method
Restart server, run client
Talk through what is going on using frames
Wow, gRPC is great, lets throw REST and JSON away
There are some drawbacks to gRPC
-Modern browsers have great support for browsing HTTP/2 websites
-But browser JavaScript APIs for making HTTP requests haven’t caught up
-JavaScript’s XMLHttpRequest and fetch do not provide low level access to HTTP/2 frames
-Not possible to build a gRPC client in the browser
Workaround today is gRPC-web
-Built by the gRPC team
-Provides limited support for calling some gRPC services over HTTP1
-A server proxy then translates between gRPC-web calls and normal HTTP/2 gRPC
-Does not support bi-directional streaming
HTTP/2 and Protobuf are small and fast
-But they’re not human readable
-Binary, and properly reading a gRPC message requires the proto file
Additional tools are required to debug gRPC calls
-Here I am reading a gRPC TCP packet in Wireshark. It has some support for gRPC
-It can recognize a gRPC packet from content-type headers
-It can see that this is a response for a the SayHello method
-gRPC message is still mostly binary
There are workarounds. Most gRPC services use protobuf, but JSON can be used during development
Open the demo project
Show the HelloHub.cs class
Show the index.cshtml page where the signalr scripts should be included
Run npm install @Microsoft/signalr from within the wwwroot folder
Call out that in 3.0 it moved to @microsoft npm org
Add the HTML code to include the file, either after copying it to wwwroot/js or leave it where it is. HTML code is below. <script src="node_modules/@@microsoft/signalr/dist/browser/signalr.js"></script>
Show the services.AddSignalR() call in startup.cs
Show the endpoint-routed SignalR endpoint in startup.cs