gRPC - Real-World .NET Core/.NET 5 Applications

[@VinuP2023]

Thank you Shiv. I noticed you have enabled ads now. I make sure every time to watch the advertisement completely, however lengthy it might be, to thank you for all your hard work. I know its nothing for the work you do, but its a small token of thanks from me 🙏😊

[@Matlus]

Thank you Vinay! Yes, just just turned them on!! You noticed!. And thank you for watching the ads, really appreciate all of our help and consideration Vinay.

[@cheesypufs]

Nice video series Shiv. If I may add some constructive criticism, please show the code on the screen for longer, right now you pan the video between the code and yourself and I'm having to rewind and pause a lot just to get a better look at the code. So I suggest either keep the video showing the code only or if you want to show yourself to explain a concept then bring it up within a small picture-in-picture format so we can see both the code and yourself. Thanks for your tutorial series!

[@Matlus]

Hi Frank. Thank you for your feedback. I'll think on this. FYI - The code is generally available on my gitHub :)

[@chanakyakumar]

Again quality content. I really apricate you taking time in explaining why you need to do certain thing instead of Just showing how it's done. it does provide a prospective. On other topic I was going through the ASP.net core documentation and stumble upon 'Route to code' and could not wrap my head around why would we need something like that ? May be once you have some time you can have an explainer video about that.

[@Matlus]

Thank you Chanakya. Appreciate the comment. As regards the "Route to code" feature it's similar to what I talk about here: kzbin.info/www/bejne/aHK0nZdpibGAl8U Essentially the ASP.NET Core framework is really fast. When you add the Web API or MVC toolkits things get quite a bit slower. So if you need that extra performance and don't care for all of the fancy features Web API/MVC have to offer, you might just want to use "Route to Code" It's not the best name for the feature :)

[@xStepBrother]

Great video shiv! I have really enjoyed listening and learning from this, I may be mistaken but there is no tutorial/documentation on how to use gRPC outside of localhost. If you have any reference to where I could find that information, I would greatly appreciate that! (specifically talking on connection via IPv4 address)

[@Matlus]

Hi Roman, glad yo hear these videos are helpful. I don't understand the question. local host is just an IP or URL. Use the URL that you need. While developing on your machine, you'll use localhost unless the server/client is remote. So just use the URL/IP address you need. If I'm not understanding your question correctly, please provide more details as to the nature of your problem or what exactly you're trying to do and I'll try and help

[@stephendavidson1237]

Great content Shiv, thank you for taking the time to share your experience with us! I was wondering if you would share your thoughts on using gRPC Interceptors to house the code that translates exceptions instead of using mapping methods inside the Gateway classes. Just because this is technically possible, I'm struggling with the idea of doing it that way. Using interceptors feels like I'm hiding away valuable knowledge of my system.

[@Matlus]

Thanks Stephen! You're correct about the feel you have. I have similar concerns myself. However, in ASP.NET Middleware is where such things are done. When I first started with ASP.NET Core, I also resisted using the middleware. But in larger projects, because the middleware intercepts all traffic, it is in fact the best place to a a single try-catch for the entire system since it is the true "entry point" of the system. The alternative would be for each of the Controller actions (Web API as well as GRPC) to have their own try-catch. Not only is that a lot more code, but more chances of being implemented incorrectly. The particular project, supports both Web API and gRPC, but the middleware code is the same no matter the kind of protocol in use. That's a big win. If you look at the tests, you'll see that I actually have tests in place to ensure that controllers in fact DON'T have any try-catches in them! I hope that convinces you :)?

[@obiwanjacobi]

There is a security aspect of communicating exception details over the wire. You really have to make sure you're not exposing any internals that can be misused/abused. I would also filter out any exceptions that are not domain based (you have domain exception base-classes you can catch on) and package them into a generic technical 'call your admin' exception without any details (your Internal status code?). Also throwing an Exception (not a specialized derived type) in the client is not the best IMO.

[@Matlus]

Security aspect? Sure but "security" depends on sooooooooooo many things, don't you agree? Messages are intended to be received. stack-trace and inner exceptions details are logged local to the service. filtering? Sure, if that what you need. The code was just an example of where, what and how to do. In most of my systems I don't have a need to filter. All exceptions are intended to be see by the caller. Callers are required to propogate exceptions all the up the call stack as well as call chain. Only UI shows/hides exceptions based on technical (inform of exception but don't show details) or business (show message to user). Throwing "Exception"? Yes, I agree of course. That was just an example.

[@obiwanjacobi]

@@Matlus I do not agree with allowing all exceptions to go over the wire. In my mind it is the same as with methods - we work on a need to know basis, and you just don't need to know. ;-) I don't mean, return 200 when there was an error. I mean make it a general one if it is not a domain/business exception. If you need to find out what is going on, I'd rather use an 'activity Id' that flows with the call chain and is logged with the exception. That way you can correlate (distributed) log entries for client and server and obtain a clear picture what was going on. Azure App Insights does this and works great IMO (for larger distributed apps).

[@Matlus]

@@obiwanjacobi I guess each paradigm has their advantages/disadvantages. In what I do the reason/cause is apparent all the up the call chain, in what you do, you have to mine log files of all applications or a central log warehouse for a correlation id and then discover the reason/cause. The need is the same. We're just going about it differently.

[@ClintonVincen]

Great video Shiv, wanted to know if gRPC will be suitable if you want to implement a communication component for broadcasting messages to multiple clients ? Thank you once again for your amazing well curated content 😊

[@Matlus]

Hi Clinton, Thank you for your kind words! Typically when you say "broadcast" it implies UDP and not TCP. For TCP broadcasting, you'd have to know of each client and connect to each and send message to each. Don't know your scenario but if I have a need like this, I'd use a message broker instead. Message Brokers would be the correct/better choice for that kind of scenario. See my videos on message brokers (there is a Play List as well).

[@ClintonVincen]

@@Matlusthanks for your reply, ok will check it out, we were looking at replacing our existing socket based implementation using gRPC. From looking at the grpc docs, I'm of the opinion that grpc may not be an ideal candidate mainly because grpc server does not have push mechanism.