High-performance Services with gRPC: What's new in .NET 5
ฝัง
- เผยแพร่เมื่อ 11 พ.ย. 2020
- gRPC is a high-performance RPC framework used by developers around the world to build fast apps. In this talk you will learn about what's new in gRPC for .NET 5, like performance improvements, gRPC-Web, Blazor WebAssembly support, Hosting on Http.sys and IIS, and OpenTelemetry.
Get your questions answered on the Microsoft Q&A for .NET - aka.ms/dotnet-qa
Learn .NET with free self-guided learning from Microsoft Learn: aka.ms/learndotnet - วิทยาศาสตร์และเทคโนโลยี
Mr .Newtonsoft himself!
Unfortunanetly, his name is not Jason (
This is one of the best presentations from .NET Conf 2020 that I've watched so far. It's clearly presented, practical, and well-organized. I appreciate that it introduced the high-level concepts instead of assuming viewers were already familiar with gRPC and how it relates to e.g. REST, but still dived into a meaningful example without relying on a lot of preexisting code or complex snippets. The content density was perfect; afterwards, I felt like I had a good understanding of not only when I might want to use gRPC, but also how to go about creating a new gRPC client and server. Future .NET Conf presenters should watch this talk and strive to achieve a similar standard.
I didn't know performance was so different, thanks for the presentation.
Thanks for a great informative video - I actually physically cheered when you got to the part about the payload being generated for machine readability and not just so it looks nice in a text editor! Back in the 1990s we used TLD to squirt data between mainframe operating systems, a very efficient way to store, move and unpack data, then eventually moving to Windows development using named pipes and sockets to squirt custom packets of data around, but gradually things like XML and then JSON and REST came in vogue... I mean, repeating the field names in every record... and sending whatever free text I fancy and maybe it'll be internally consistent, and perhaps the other end will know what it all means.. really??? I'm so glad to see that gRPC is moving the other way - thanks again for the video, I am about to start learning gRPC, it looks great :)
Thanks James, That was an excellent introduction to gRPC.
Note that protobuf can be replaced in gRPC with a far more efficient binary serializer. You'd also avoid creating a Protobuf grammar. You could also create a custom serializer that could fit a lot more data into the stream.
One of the best demos from
Net conf
13:15 Thanks for zooming in
The analog of OpenAPI (Swagger) to gRPC is gRPC Reflection, not just the .proto file. In addition to the pure gRPC and gRPC-Web, with some annotations in the .proto file, you can generate OpenAPI (Swagger) docs as well as REST (or at least JSON over HTTP) endpoints for HTTP/1.1 using gRPC-Gateway.
Very cool presentation !!
welcome back to a much nicer version of remoting.
I think this is very promising, especially for cases where performance is more paramount than other properties. The key to impact (part from the performance) I suspect would be stability and portability along with ease of use. The latter part seems to be a checkbox on right out of the box. As for the portability I mean ease of swapping a REST implementation to a gRPC implementation. If the overhead of optimizing something using REST by going gRPC is too large - it may not be worth it. Well, that's a guess on my part. As for stability, one would take that for granted but it's worth mentioning.
This was fantastic
Thank you very much.
Thanks for the post . Will it perform for a large message payloads ? What is the recommended message sizes for an optimal performance?
Where can we host gRPC on Azure?
Mr .Newtonsoft THANK YOU FOR SAVING US SO MUCH TIME WITH YOUR JSON PARSER/WRITTER :D
May I get the project to show it in my work?
What is the best way to handle sending a null or undefined value? in JSON, if I wanted to send something to the server, but not have one of the fields updated ... I would exclude the node from the payload. How would you handle this with gRPC. Do I need to create a new type for each current type that has a HasValue flag?
"Lets' browse to that in a browser" and opens up Edge xD
Overall great presentation, thanks!
Is it supported in xamarin forms now ?
the shared protos create a dependency between client/server, but still great performance improvement also i liked streaming feature !
This!!!
Why can I get the code of the comparison between json with GRPC?
New Subscriber Here!
I was wondering if it were possible, on windows Server 2012R2 (IIS8.5) to do some sort of proxy for Kestrel so I can use gRPC on it? (since Kestrel does not check for a domain name)
Love this content guys but can you encode at 1080p at least and keep the code window maximized. James is a nice guy but if you’re showing code, turn the video off.
Is there any tool available for benchmarking?
What is he using to draw on the screen in real time like that?
ZoomIt. It's a free Windows tool - docs.microsoft.com/en-us/sysinternals/downloads/zoomit
Will gRPC eventually take over Microsoft SignalR?
The mind behind newtonsoft!!!!??
Oh my, I didn’t realize it could be him, if that’s the case this man is a legend amongst legends
Yes he is author of JSON.net
WELL FOR gRPC YOU NEED NEW OS. WITH REST API EVERYTHING CAN HOST IT AND CONSUME IT.
I don't know man... this seems to me like binary WCF. Ok, maybe without a ton of extra runtime infrastructure, but sill opaque binary messages that you need a code generator to read and write. Wasn't REST(like) supposed to be better for plenty of reasons?
I think the sole purpose of grpc is the performance. when you don't have any other options to gain the performance you need, grpc is the final solution. otherwise it's not just worth it.
I implemented an auto completion feature with REST and the client asked for it to be faster, I swapped it with gRPC and he got angry at me for not using that from the beginning, the speed difference is palpable, the auto generated classes are just fine once you get used to them, just add implicit conversions to your own classes and you’re good to go
@@DotNetFun having strongly typed auto generated client in every language you need can be a godsend for maintainbility
@@willinton06 Did you try compression before switching to protobuf?
@@DotNetFun
They said that about soap and rest too
Grpc.Core.RpcException: 'Status(StatusCode="Internal", Detail="Error starting gRPC call. HttpRequestException: The SSL connection could not be established, see inner exception. AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot", in console app. how to solve this
solved
great api, how does my website consume it? "It doesn't" .... Back to REST then.
gRPC is used to improve performance, but when you look at all this code generation (which someday you'll need to support and debug) you start remembering how hard was doing things 15 years ago, so we just need to get used to it again...
Code generation is mainly for convenience, since C# is strictly typed, so you get the type safety. You probably could make gRPC calls without any generated code, but that would be more error prone and not as straightforward.
I am using ReactJS for my client side. How is it possible to implement this gRPC without support from javascript apis? loled. Too huge of a change to implement this. Will wait for better support first.
I do not understand, why you are comparing gRPC with simple REST API? I think it must been SignalR with MessagePack serialization and i think it was be more interesting comparing it with gRPC...
Because it would be inferior with its default protobuf for serialization vs SignalR. Protobuf is allocation heavy and a cpu hog :/ . Flatbuffers would be a better fit. Its possible to use it with GRPC.
I can't seem to publish a grpc service to an azure app service. I tried changing the app service to use http/2 but Visual Studio still gives an error stating that it can't publish to http 1.1. Will this be supported soon?
As far as I remember, g in gRPC stands for Google, but it's not even mentioned in the video 😄.
To be fair, grpc.io itself barely mentions the little 'g'. I am not a fan of Google in general, but protobuf and gRPC are great tools.
Hmmm, all those links take me to the official German Microsoft Homepage and offer me to buy the newest Surface Book for Christmas. So either the links are wrong (which I don´t think)or Microsoft is playing the game again to reroute people by their country because it can´t be that a german developer would want to read an english documentation - so we better take him to our german homepage to prevent him from getting lost.
Why are you using a PREVIEW version of Visual Studio??🤔
Still, we can't generate the proto from our controllers... The code must be the source of truth, just like we do with WebApi or CodeFirst. This is the unique new feature that isn't designed like the others...
Because its contract is expressed in a neutral language. You must learn how to write a protobuf file or use tool to generate that file from C# code (which is mentioned that available now). However knowing about the protobuf file would give you much more control on the contract. I do believe that learning the protobuf language is not time consuming, it's fairly natural and friendly.
The proto files are super easy to author and read.
But if it's not generated from code, you can miss that you have to update the proto. With autogenerated Swagger files (that you can also learn) that won't happen. And you won't have conflicts of someone also modified it. We are returning to WCF big interfaces...
@@SkillisForNoobs The extension showed refs the proto file in the csproj and it WILL do the compile automatically.
"And you won't have conflicts of someone also modified it." This is nonsense. It is a simple, easy text file. If you can't manage a proto file, you sure as hell are not a developer.
So basically WCF i back.
I bet that it's simpler than WCF. That's really awesome and promising.
@@justnothing7080 Hopefully it is simpler. WCF was ahead of it's time but too complex for everybody to use.
Not the same. Don't make uninformed comments or you risk embarrassing yourself.
What a bullshit about contract first and content first? Any REST service with fixed formats of messages can be called "contract first". The only present advantage of gRPC is full duplex connection between server and client.
That's cool and all but who the fuck uses the light theme in vs?
Nats faster than gRPC
Maybe it's just me, but I absolutely hate GUI tools that magically adds dependencies, and generates a bunch of critical files.
Does gRPC libraries work the same way in other languages? It feels like .NET always tries to hide the code from you, which makes you lose control of the project.
You can manually add the nuget package and call the grpc compiler manually if you would like. You can even just manually add the few lines to the csproj as well.
@@bl0rq i don't like the fact that it generates C# code that I have no control over though. I have no idea what that code does, and if something goes wrong there really no way to fix it, except to modify the generator in the .NET repo.
@@WorstDeveloper You are always running code you have limited control over in libraries. This is a weird complaint. The code does what it is supposed to and is auditable. And if you really want to waste your life, you can hand roll your own because the whole system is open and documented. What do YOU use to do what gRPC does?
@@WorstDeveloper The whole point with code generation is to keep the client & server code intact. Any manual change to these critical components is asking for trouble. The proto files and the generated code is quite simple. All you need do is to design the interface, write the implementation and leave the communication details to gRPC.
First :)
Has anyone contacted you to ask for your address so that they can send you a certificate or some kind of badge or medal for your such a great achievement of being the first one leaving a comment?
@@justnothing7080 😂😂😂
nah.
Back to CORBA hell. Where exactly is the innovation? Old wine in new bottles, nothing more. Unfortunately, the computer science story is being ignored again.