Episode 39 - gRPC with Mark Rendle

So first thing I’d like to do, Mark is thank you so much for spending the time to be on the show.

No problem.

It’s a bit of a different situation, usually because we usually record remotely. And you know, I’m in London for an event and you you were saying, “I’m around the corner.”

Yeah. it’s less than an hour from home. So…

There you go, right? It just kind of make sense.

So yeah, I greatly appreciate you making your way across London. And during busy commuter time as well. So…

Yes, I’ve may not have planned that one particularly well, but it wasn’t too bad.

Okay, well, yeah. Like I say, I appreciate that. We’re in the hotel at the minute, which is, you know, interesting. I won’t say which hotel because we might get in trouble. But, so I figure

It’s one of the really, it’s the Waldorf Astoria.

Yeah, we’re staying at the Met or wherever, you know, one of those really posh ones. That’s the one.

So yeah, just maybe could you potentially introduce yourself to listeners, and maybe to myself.

Yeah, sure. So I’m Mark Rendle. I have been, this is my 30th year of professional software development for a given value of “professional” - for some of it. But yeah, I’ve been doing this since I was 16. And I’m still coding and not particularly managing and not sort of looking to get into that track. I still love learning new stuff and and staying on the cutting edge of the things that are coming along, playing with new things, and hopefully I’ll still be doing another 30 years. Because I get to retire by the time I was 76. So…

I’m hoping to do, the you know, the programming stuff that I do for as long as I possibly can. I feel like so I get in trouble with my other half because I’m always the computer doing something.

And I feel like I will be either die out the keyboard or be slowed have crowbared away from it. When rheumatoid arthritis sets in, and I can’t move, and I have to be sort of dragged away.

Yeah.

Yeah, yeah. And the reason I mean, I’ve got two kids, I’ve got a 13 year old girl and an eight year old boy. And I was worried that I wasn’t spending enough time with them. So I decided to teach them to code. And now I’ve got a 13 year old girl who is building an iPhone game in Unity. And speaking about Unity at conferences, which is terrifying.

And me and my little boy remaking Club Penguin. He draws pictures with felt tip pens, and we stick them on the scanner, and cut them out in Affinity Photo, and stick them in Unity, and then make it move around. And we’ve got a sledding down a mountain game in there, and so yeah, it’s great. I get to spend time doing what I like doing and learning Unity and spending time with my kids and doing cool stuff with them. So

That’s awesome. Yeah, I love to hear about stories like that, and especially when it’s like receptive on both sides. Where it’s not just, “I am parent, I will teach you to code and you will do what I say.”

Oh, yeah, no, they get to watch me go, “I have no idea why that’s not working, let’s see if we can find out together.”

But that’s an important skill to learn. And it’s an important, like position to be in where you can go, “you know, it’s broken, and I don’t know why.”

Yeah, and I think it’s really useful for kids to know with the grown ups don’t just know everything straight away, and it’s okay to not know things and have to go and find them out, and go and look for Stack Overflow or whatever. Yeah, to find the answers. So

Exactly. I was having this discussion with someone at work the other day about: there’s so much to know that, no, it wasn’t, it was on it was on a different recording. I was discussing with someone on a different recording how: there is so much to know about one specific topic that even if you study that one topic for 15; 20; 25; 30; 35 years, you’re still not going to know it all. So the thing that came up was C# as a language.

Yes.

Even if you’re on the committee that decides, if you are Mads Torgersen for instance, there will be parts of C# that you didn’t know, not really existed, but you didn’t know that you could do things with in that way.

Yes.

I mean, when I, the book, that I’ve just finished working on, and that was going through review. And the people reviewing it, some of them were on the team that’s implemented gRPC for .NET. And I put something in the book, and one of them - I won’t mention his name - but in the in the GitHub issue went, “Oh, I didn’t know that.” And obviously, you know, there was also a huge amount of stuff where he was going, “but you could do this and we’ve got that and whatever.” So I was learning a lot about it from from doing it.

But yeah, nobody knows everything. I’m sure there were even things you could; actually very early in my speaking career, so I started speaking at conferences 10 years ago. And I think it was the third DDD - developer developer developer - day. And I was doing this talk on functional programming in C#.

Yes.

And I thought it was like, the most insanely complicated and clever stuff. And I was doing it DDD Reading in 2009. And Jon skeet was in the audience. And I kind of went, “Oh, okay, this is going to be fun.” And but yeah, and he was watching. And I’d actually sort of thought of doing things. I had other thing, using generic extension methods to do what try and catch but with more than one exception type, which hadn’t occurred to him.

Right.

You know, and then he was kinda like, “oh and you could do this with it, that with it ,” and we ended up pair programming on the ideas he’d had while I was doing the talk and everything. So yeah, you can learn something from everyone and you can teach everyone something. And it’s important to remember that.

Yeah, yeah, most definitely.

And actually, my eight year old talking about programming again, he teaches me about testing. ‘Cos I go, “there we go, it worked on,” it’s got like clothes the penguin can put on clothes. And so I made it so that the penguin could put on my hat. And I went, “right. And the others will just work,” and he went, “no, we have to test them all.” And I’ml ike, “Oh, god, you’re gonna be so useful when you grow up.” Yeah, so yeah, he’s eight, and he’s teaching me stuff. So that’s good.

That’s it. I love that. I love that. Yeah, and it’s, it’s being able to like having someone there who can see from a different point of view. And one of the best things that I think for big teams is to do a lot of pair programming, and peer review, and sometimes mob programming. Because if you’re pairing with someone who’s at the keyboard, you can hit them with, “yeah but, what if?”

Yes.

And you can see it straight away. Because they’re in that state where you can’t see the wood for the trees. Yeah, whereas you’re maybe 10,000 feet away going, “but what if I do this? What if I poke at one of these? What if I pass in a null or something?”

Yeah, yeah. Or the thing I always find a pair programming is you kind of watching them type something and you just go, “you come back to that after lunch, you’re not gonna know what it does. I don’t know what it does. And I’m watching you type it.” Yes. So yeah.

Yeah, definitely.

Okay, so we’ve hinted a little bit about gRPC already.

Yes.

I would love to talk to you about gRPC in this Interview.

Ok.

Could you tell us a little bit of what grPC is? I know that there’s RPC which is a remote procedure call. Is this like gnu, Google, or some other thing?

The G doesn’t stand for anything. On various different releases, they’ve said it stood for different things like: “graceful” or “gigalicious” or whatever.

But no basically, so RPC is a pattern for doing distributed systems so that you can have a process running on one machine talking to another process, potentially running on another machine. But in a way that looks like you’re just calling a function or calling a procedure. So it’s intended to hide the fact that there are sort of a mobile phone network; and multiple masts; and a fibre optic cable; and the Atlantic Ocean; and then more of the same at the other end, between you calling that function and executing and something being returned from it. And that pattern is old that’s been around for as long as we’ve had multiple computers on the network trying to do this sort of thing. And 10 years ago, there was the problem - oh 10-15 years ago - people were building applications in Java with Enterprise Beens, and people were building applications in .NET 1.1 or .NET two, and people were building applications in Python and other languages. And they wanted to be able to make remote procedure calls between the different languages. So you can have something written in Java and something that was written in C# calling it and not sort of worrying about what was in between. And so they invented SOAP.

The Simple Object Access Protocol.

Yes

And SOAP, because at the time they believed that every problem of communicating data and serialised and deserialising data was best solved with XML. But the people who invented SOAP figured that the problem with XML is that there wasn’t enough of it. And so they wrapped perfectly good XML, in a whole bunch more XML, with a bunch of XML namespaces, and called it SOAP. And the result was that - and then you send this backwards and forwards over HTTP 1.1. With the result that if you wanted to send, if you had a calculator service on one machine, and you sent it and add operation with two and two, you were sending like a kilobyte of data in that direction. And then when it wanted to respond with four, it was another kilobyte of data going back in the other direction and it was just insane. But people did it any way and it worked, and we didn’t have a particularly high expectations of computer speed and whatever.

And then Google came along. And Google were one of the first organisations who actually did distributed-distributed processing. Their computer was a data centre. The way Google worked originally was MapReduce, which is thousands of machines, potentially, your search request goes in, and it gets spread across to hundreds of different machines. And they all bring back results until eventually it popped into the web page. But it did it really quickly. And so Google needed a way to ship the data as quickly as possible between the machines. And also something that was easier for the machines to understand than XML. XML is actually quite hard. I wrote an XML parser recently and it is much, much harder than it looks - especially with namespaces and stuff.

And so Google created Protobuf. And Protobuf is a binary format. And it’s designed to be a) very, very small, like almost as small as it can possibly be. And b) very easy for machines to read and write. And so they were using Protobuf, and they were bouncing that around over their networks. But it was still the overhead of HTTP calls and the overhead of networking. And everything was was still slowing things down. So then they invented their own RPC framework internally, which was called Stubby, because RPC, the things that on either end that you actually call are referred to as Stubbs. So the client that you generate from a WCF application, for example, is a stub which then ships things across and so they created Stubby and Stubby did its own networking entirely. It was just TCP sockets, and they handled framing and boxing and all that sort of stuff across there. And that’s what they’ve been using internally for years and Stubby worked, you define what your thing would look like, and then it generated C++ code; or Java code; or Python code for you, which could then talk to the other thing on the other end. And they were using it internally.

And then HTTP two came along. And HTTP two, which was basically Google anyway, because it was SPDY, or ess pee dee why. And HTTP two is a lot faster than HTTP one. And it supports all kinds of amazing stuff like streaming and multiplexing. So you can have a single HTTP two connection with hundreds of requests all going backwards and forwards, and there’s no head of line blocking so you can send a request, and it will get a response immediately. And there’s older request and everything. And I don’t know, the exact story, but you know, basically Google look to HTTP two and they said, “this is doing most of the complicated stuff from Stubby, let’s rewrite Stubby on top of HTTP two. And let’s make it public. So that we can actually expose API’s to developers on the Google platform.” And so they did that. And they called it gRPC. And that’s been around for a few years now for five years, basically, around as long as HTTP two has been available. And so yeah, we’re getting access to this insanely powerful, fast, highly optimised protocol that Google has been using for their internal intra-microservice communication. And now we can get it and we can use it. And as of ASP. NET Core three, we can do it properly in ASP. NET Core.

Excellent.

Which is awesome.

Yeah. So we can send cat photos to each other even faster

even send cat photos without the overhead of a SOAP envelope.

Fantastic. Sign me up.

Yeah, absolutely.

Excellent. Okay, so that covers a little bit of what gRPC is. And yeah, and one of the things I was going to ask is, is it related to HTTP? Because HTTP is kind of like an RPC, it is a remote procedure call: “give me this thing; give me this thing.” But yeah, I mean that’s essentially answered all of the other questions about gRPC was great.

Okay.

But yeah, so, so then, could you talk a little bit about the book then because you’ve done you mentioned it there, you’ve done a “ gRPC for WCF Developers,” book.

Yes.

You said you were finalising it, it’s not quite finished?

I’ve just had a bunch of what Microsoft people refer to as “nits”.

Right.

So there’s one more pull request to go

You’ve had a number of nits?

A number of nits to fix. And then they will take the preview edition bit of the graphic and it will actually be on Microsoft’s .NET Architecture section. So you can get the preview version already. They said, “we want 50 to 75 pages,” and I finished it and then freaked out because I thought it doesn’t feel like I wrote that many pages. And then I downloaded the PDF and it was 108. Because it’s a big subject.

Yeah.

But basically, so there’s two things that have happened back in Build earlier this year. Microsoft said, “.NET Core 3.0 will be up in September. 3.1, which is the long term service release will be out in November. And then next year, the next major version will be .NET Five. Not going to call it .NET Core Four because there’s a .NET Four and we don’t want people getting confused. And we’re not going to call it .NET Core Five,” because as far as Microsoft are concerned, this is now where the development is happening on .NET.

Yeah.

So .NET Core is the future of .NET. And if you’re running on Windows, you can create Windows Forms applications; you can bring over your WPF applications; UWP applications. And I haven’t actually tried it particularly, I’ve copied some XAML across and that seemed to work okay, but there’s going to be things if you’re using like control libraries from Telerik, or DevExpress or something, then that could potentially be challenging.

The crazy thing about XAML is there’s no standard. So Xamarin XAML is different to .NET XAML, is different, perhaps if there’s a Mono XAML.

Oh you should try Visual Studio SDK XAML, that is a whole other thing. You don’t want to hear about that.

But yes, so, and most things, so you can create ASP. Net Applications, you can create Windows services and Linux services and all these things. But there are some things that were on .NET that are not being brought over by Microsoft as kind of first class supported things. And the two big ones that people are very upset about is WebForms and WCF. And WebForms is really, really complicated and it is basically just, I don’t know what to tell you. They’re saying, “if you want to migrate your WebForms application then go to Blazor.”

Yeah.

It’s very, very different. So we’ll see how that goes. But WCF is an RPC framework. And that will get people leaving angry comments on the, on the page.

I don’t allow comments on the website.

Excellent.

Yes, it’s just an RPC… no it’s not. WCF is a whole, really, really advanced and insanely powerful communication framework. And it was created by Microsoft. Because people wanted to be able to write SOAP applications, but they didn’t want to have to hand write WSDL files and all this other stuff. But WCF also has NETTCP binding, which is really fast binary encoding, which only works between WCF client and server so it can’t talk to the Java for example. And Microsoft said, “nope. We’re not doing WCF. WCF is legacy.”

Okay.

“And if you are using WCF, then we recommend migrating to gRPC, which by the way we are supporting, going forward.” And grPC is very much in tune with Microsoft’s, “we’re open, we’re open source, we’re following open standards. We’re not doing that Microsoft thing of looking at what’s out there and then going, ‘we can do a better job than that.’” They’re trying to tear down the walls of the garden, which is awesome.

Yeah.

But looking at some of the reactions, WCF people, they’ve been building systems on this for 10 years now. It was 2008, I think, was the first version of WCF and these are big enterprise organisations or public organisations. We’re talking millions, 10s of millions of lines of code All of it is tied to WCF. And so I started blogging about, “actually look, gRPC and WCF are not that different. And gRPC can do most of the things that WCF does. And if you’re, if you compare WCF, doing SOAP over HTTP to gRPC - and there’s no option there, it’s Protobuf over HTTP two - then gRPC is a lot faster, it uses a lot less memory.” Something I want to try in the near future, is I’m going to create the same application in ASP. NET Core three grPC and benchmark it on a Raspberry Pi, against a WCF application doing SOAP over HTTP running on a big Xeon box. Because I don’t think they’re going to be that different. And I think that in itself is a big opportunity.

But yeah, Microsoft, I know quite a few people at Microsoft from the speaking circuit and from generally being a loud mouth and making a fuss on Twitter about things - although quite often I’m the guy sort of diving in the going, “Oy there’s no need for that, leave him alone,” and defending them, which probably makes me more popular there. But they said he said, “we need somebody to write a book. Do you want to write the book?” and I went kind of like, “err. Yeah, okay.” And I was already up to my eyebrows with my day job, and this product that I’ve been struggling to get ready, but my wife is she’s just started a creative writing masters, and she is very good at writing, and she has written used to work for central government. And she wrote white papers, you know, the things that leak never leaked because of her. But she used to draught these things. And they’d be read in the House of Commons and the House of Lords. And so she’s good at writing, and she’s good at organising writing and everything.

And I said, “Can you help me write a book? If I explained to you the stuff, then can you help me actually just turn that into words that people can read? Because I can’t just download my brain.” And so she helped me a lot with with that, and she’s not remotely technical, which is great, because then I would kind of go, “I’ve written chapter three!” And she would sort of take one look at the first line and go, “Why, what is this? Why is this chapter existing? What are you going to be telling me?” and I’m like, “Okay, I’ll go and write an introduction.”

So we’ve ended up with a better book than we would have done. But yeah, and it sort of explains the history of grPC, and Protobuf, and the syntax of proto files - which are the files that you compile to create your stubs. And then it dives into the various types of WCF service that you might have had. So simple request-response; and the duplex models, including full duplex; and looks at how you could do those with gRPC. And also talks about things that you can’t do with the gRPC that you could do with WCF. And some of those are, okay, not so bad. So there’s no interfacing with a queue - in WCF you actually had a binding that would put things on MSMQ and you can’t do that with gRPC. but you know, just put it on a queuu, that’s not that difficult. The one that’s going to make people are going to find the most difficult is transactions: WCF distributed transactions were dark magic. And they are not going to be easy to replace, and people are actually going to have to find different modern ways of doing things without distributed transactions. But yeah, so there’s there’s an appendix at the end of the book going, “sorry. There were no transactions.” But it gives, I used the stock market as an example, because I figured that was probably reasonably close to home for most of the people out there who’ve got these huge WCF applications.

much better than just a simple “Hello, World.”

Yes. Yeah. I mean, the demo Microsoft used .NET Conf was a weather service that sent updates, which was great because it demonstrated streaming, whatever. But I wanted to do examples that were a little bit more “real world”. I’ll probably get comments back going, “That’s not how you calculate how many shares some body owns,” but you know, that’s fine.

That’s an implementation detail.

Yeah, yeah.

And so yeah, the book is on Microsoft on docs.microsoft.com. And hopefully, it’s enough to get people started with gRPC. And I’m going to be blogging about it; speaking about it; delivering workshops. This is my focus for the foreseeable future. I’m going to be the man who saved the world from WCF. Or at least saved them from the WCF boat being torpedoed while they were halfway across the Atlantic on it. So yeah, I think if I can do that, then I’ll be happy.

So if we take a step back then: imagine I’m not a WCF person, I’ve not built any apps with WCF.

Okay.

Right. I feel like I know the answer to this question: Do I need to use gRPC for an app or is it just literally a tool in the toolbox that I can implement if I want?

It is a tool in the toolbox. There are times when I would say, “it is the best tool, it is the one you should pick.” And there are times when I would say, “you can, it wouldn’t hurt.” And there are times when I would say, “not that.”

So it’s all about API’s effectively. It’s: this machine wants to that machine to do something or ask a question and it wants to get an answer. If you have a public API, so take the GitHub API, for example. That is big, and GitHub have actually done a very good job of making that properly RESTful, I think it’s like level five hypermedia. So objects you get back have links to other resources and so forth. And it’s a very resource focused API. And they want - its public - and they want everybody to be able to access it. So that JSON API’s, and actually JSON probably over HTTP two now because most services supporting that. And so some of the slowness of HTTP one has gone away. And you can still you can do the persistent connection, you can do send multiple requests, get multiple responses. You can even do clever things where the server can go, “Hey, if you asked for that, you probably want this, “and push stuff that you didn’t ask for.

So for a public API, then JSON; HTTP. Yeah. for public API’s, JSON; HTTP; perfectly fine. Nothing wrong with that at all. For smaller API’s that are not a huge amount of traffic as well: if gRPC feels like an extra layer, complexity or, you know, you’re in a hurry, your boss wants it by Friday, and you know, ASP NET Core MVC, you know controllers, you know dependency injection, and serialisation, and Entity Framework and everything, then by all means, bang it out using controllers.

If you have an environment where you’ve got a lot of traffic bouncing around, and particularly on an internal network or a microservices cluster, like on Kubernetes, or a Docker swarm or something, you want to be using as little processor power and as little memory as possible to handle the serialisation and you want to be generating as little network load as possible between all these nodes in your cluster. That primarily is where gRPC comes into its own - that’s what Google built it for, after all. But the other areas where people are starting to look at it is if you are delivering services over bandwidth starved connections like 3g connections in developing countries, or even 4g connections at football matches where the cell is completely overloaded, then using gRPC as the communication protocol for a mobile device to talk to the server helps a lot. And I believe there are people doing NET code for probably not games like Fortnite or Forza Horizon or anything because that is really highly tuned. But if you got like a casual game, like Words with Friends or or something like that, then you can get away with sort of not the sub millisecond latency, but you still want it to be quite quick then gRPC is quite good for there as well. I haven’t actually got around to seeing if I can get Unity using gRPC, but I’m going to try, because we’re going to try and make a multiplayer version of Club Penguin, see. And if we do that, then I’ll see if I can drag in the gRPC libraries, now that Unity supports .NET Standard.

But yes, so it’s the one place where I would say it is an absolute no brainer, though, is Kubernetes cluster, Docker swarm cluster, or even just the equivalent internal network where lots of messages and you’re really doing a good job of breaking things down into lots of services. And it helps keep traffic down. It helps keep costs down with processor time and everything. Helps keep your carbon footprint down for that matter.

And it also means that you get less of a overhead. So one of the reasons some people resist microservices like Stack Overflow resist microservices, because their response times are insanely important to them. And they are; you go to Stack Overflow, and that page loads and you just kind of like, “I don’t even want to think about what went on there.” Google’s home page, well let’s say Gmail, Amazon pages just load breaking things down into microservices. You don’t want to slow it down and make things appear slower but gRPC is still going to be some overhead that will be a lot less. So those are the points where it’s a real no brainer to switch over to that.

And also if you want to talk between different systems. So gRPC, the main organisation so it’s not managed by Google, it’s kind of Google’s project. But there’s a gRPC organisation GitHub. And then there are all the implementations for different platforms, repos within that organisation. It’s kind of hard to tell which ones are official, and which ones aren’t. But I have a slide which says these are all the languages it supports that I’ve been using in talks. And it’s: C++ - it doesn’t support C, as far as I can tell - C++; Java; C#; go; Python; node -but not web browser, there was a browser thing you can do; and everything else that you might want it to support in between and then you get; and Rust - which is pretty hot stuff at the moment, and they nearly [have] async and await, which is going to make Rust so much easier.

But yeah, there’s Haskell implementations. Java’s got a, Scala rather has a Scala idiotmatic one; Kotlin, has a Kotlin idiomatic one. And so, and the thing I really like about it is you’ve got the interoperability that you had with WCF when you were using SOAP, but the network traffic and the performance is incredibly close to NETTCP. It actually uses slightly less memory. NETTCP is a little bit faster. If your two machines are on a gigabit LAN next to each other. gRPC is a little bit faster if your networks not quite so quick, for some reason, I don’t understand.

Okay.

But yeah, so you’ve got essentially the best of both worlds from WCF: You’ve got cross platform and high performance and they’ve been put together into this one thing.

Okay, excellent. Okay. So we talked about microservices. Microservices is a big topic. Obviously any managerial people who are managing developers are going to hear that and go, “guys, we need to rewrite everything we’re done with microservices with gRPC we need for tomorrow.”

Yes, yes. No, don’t do that. I mean, I’m not going to talk about the challenges of breaking down the monolith into microservices, where this is everything.

Yes, and way beyond my expertise. And I’m sure you’ve spoken to people who know much more about that. And if you haven’t speak to Sam Newman, because he’s awesome.

But taking if you’ve already got microservices and they using HTTP, and let’s say you’ve got them in ASP. NET Core 2.1. There’s not a huge amount to do to change it to gRPC. It’s not for everything away and start again. Because the chances are if you created, if you’re working in that sort of micro services - or you know, not necessarily micro but distributed services - and you’re working in the kind of place that’s adopted .NET Core 2.1 you’ve probably got your dependencies fairly well separated out; you’re using dependency injection; you’ve got your startup class with your configure services and you configure and everything. You maybe even have Swagger or nSwag, or Swashbuckle to document your API. It’s not actually that difficult.

You sort of go, “Okay, here’s my, let me go and get my swagger, my open API document that tells me what all my objects look like and what my endpoints are,” and then you translate your object schemas into Protobuf messages, and Protobuf message .proto files, if you’re using Visual Studio Code, or Visual Studio, or Rider they’ve got syntax highlighting and IntelliSense and everything for these now. And just go, “there is a message it is called this.” And then you have a list of fields and its type name. The weird thing is then have “= 1”, “= 2”, because every field has to be numbered. And it’s actually the number that’s used in the serialisation format. And so, both things at either end have to agree that field number one is the ID - there’s no zero as well, it’s not zero based some reason - yes, field number one is the ID; and field number two is the title; and field number three is the first name; and field number four is the last name. And if you switch those around, you will just get weird things happening.

But other than that they look, it’s like writing a JSON schema up front. It’s like, “there is this field, and I know what type it is, and I’m just giving it a unique number.” And then you take your endpoints, which have got your URL parameters in. And you turn those URL parameters and query string parameters and everything. Use that to build another message, which will be a request message. And then you instead of using MVC, and creating controllers, you write your services define your service in your protofile. And if you’re using Visual Studio 2019, you save it, and it does a background code gen[eration] of all the code and it creates a base class that you can then inherit from, where for every RPC endpoint is defined, there’s a virtual method that you can override. But because this is not, it’s been possible to do gRPC and ASP .NET Core - and actually in traditional .NET for quite a long time Google supported it, but they supported it on top of a native Protobuf and gRPC runtime that was written in C, and so it was like a lib file or a dll file that had to be included. What we’ve got now is a fully managed implementation written entirely by Microsoft and contributors for ASP .NET Core three. And what that means is that that service class that you create that inherits from the generated base class still has dependency injection. So all your things you put in configure services; you’re getting dependency injection in there; it still can talk to Entity Framework - actually in 3.0 it can talk to Entity Framework 6.3, so if you’ve got a bunch of .NET code, and the thing that was making it, most difficult to move across was, “Entity Framework Core is not Entity Framework,” then actually yeah. Now most of it should. I don’t know about the EDMx files, but just don’t.

So yeah, it’s not a huge jump from one thing to the other. And it’s one of those things. When I first saw gRPC I thought, “Oh, that looks really complicated and like a faff, and lots of ceremony and everything.” But and at the time, you had to drop out to the command line and type protoc and then a whole line of command line parameters to generate things and whatever else. But now, Visual Studio, add new item, they’ve got a protobuf template in there, drops it into the protos folder; you put your stuff in your save; you inherit from that base class; and you’re up and running. And you’re getting all that goodness but still in that same familiar… and you know, if you want to, you can have a gRPC service and API controllers, or routing endpoints, you can have multiple things all running in the same application. Not sure I would particularly recommend it, but you can.

Okay, that’s good. That makes sense. So if you’ve got, say, do microservices or two smaller distributed endpoints, I guess, that are talking to each other that are not perhaps outward facing. You could maybe if you’re in a in an agile world, you can take a spike, take a branch, try it out. If it works, brilliant, if it doesn’t work, you’ve maybe spent two or three days look into something. You’ve learned something new. Even if you don’t end up implementing it, you will experience with it.

Yes. And if you don’t use it that time, the chances are the next time you’ve got something new to do, you’ll go, “Oh, hang on. That didn’t work for that, but it might work for this.”

Exactly.

And the other thing, which I’m getting some… I’m talking to quiet a lot of people who’ve got WCF services or ASP .NET Web API is the other one. And you in sort of proper, purist microservice environments, you don’t control the thing at the other end. And so if you go, “we’re converting this and it’s going to be gRPC,” and you’ve got 15 teams out there who are wrong depending on you with your JSON API. You can’t say to all 15 of those teams, “hey, guess what you’re spending the next sprint doing?” Because they’re going to say, “we are spending the next sprint shutting you in the fridge and throwing it in the canal.”

But if you make sure that your - this is the thing that rails people always go on about: the thing controller. So if you make it so that your thing that inherits from controller base in your JSON API is literally just a really, really thin wrapper over a class that contains all your logic. Then you can create a gRPC service wrapper over that same class, and run them both in the same application and say to people, “hey, until everyone has moved over to gRPC, we’ll just have both,”

Yeah.

“And we would encourage you to use this one, but this one is still there.” And you can literally run that in the same process on the same machine. And people can use… so you get a gradual migration over from one thing to the other, which is really nice. It means you don’t have to kind of stop the world and everybody retools and and everything else. But and for the people who are consuming your service - I know you can generate clients from from Swagger documents and everything else but - nothing really compares to, “here’s our repository, grab that proto file, drop it in your project, and it will generate you a client. And then you can talk to our API. And you don’t have to worry about it. And it’s all typed checked. And you’ve got, if I throw an exception on the server, you can catch that exception on the client. Just slightly good with WCF” So yeah, that bit that cooperation between teams thing, I think is easier with these proto files than it was even if you were very, very good with your Swagger and your Swashbuckle, and everything so, so yeah.

Yeah, I like that. I like that being able to almost sort of run a versioned api, “here is the standard sort of JSON-ified HTTP Swaggery stuff.”

Yeah.

“And here is a separate API endpoint for when you have moved over. And although you don’t need to know about it, because I’m implementing it. They are literally both calling the same classes”

And talking to the same database and everything else. Google, a lot of their public API’s, they’re starting to offer gRPC endpoints over them as well. And which makes sense for them, because they’re saving huge amounts of bandwidth on their data centres. And it makes sense for people who are considering those API’s. Because it’s like the Google SDK for .NET is great. I love the Google SDK for .NET. And some insanely smart people work on it. But you’re relying on them to keep it up to date. And if the API changes, then they’ve got to go and redo a whole bunch of stuff. And there’s some code gen[eration] and whatever in. Whereas with gRPC you go, “there’s an update. Here’s the proto file, you drop it into your project,” and you can immediately see if anything’s broken, and you need to update your calls or extra information on whatever. Yeah, it’s a really nice alternative. But yeah, do both

Yeah.

And you end up with better structured code, and then 10 years down the line when they kill gRPC because something else is come along and everyone’s going, “oh message pack over quantum entanglement!” Then you’ve got all your code is actually nicely contained and you can just wrap it in a quantum entangled message pack facade instead.

Exactly.

So, yeah. It’s all good.

I like that, quantum maintenance message as a service.

Yes, yeah. IBM will be doing that.

I think that goes back to the sort of “well designed”, and I’m going to put bunny quotes around that because design is different, you know, in different situations. Good design is different. So you know, a separation of concerns, following the all of the different principles that we supposed to follow like dependency injection, and single responsibility - these work really well in some really good areas, but not so well in others. But if you follow those anyway, then yes, you should be able to just go, “Hey, we’re using HTTP as a dependency,:” thinking about, for instance, the HttpClient, take that as a dependency.

Yeah.

And then when you’re ready, just swap that out for gRPC Client, I guess.

Yeah. Yeah. Yeah, in the same way as in .NET. Core, you can add HttpClient as an injectable service. And then you can, you can get an instance of HttpClient, or you can get the factory and ask it for an instance. Or you can create a type that takes an HttpClient in its constructor, and then you can add that, and it wraps it with all the Poly stuff and all the retry semantics and everything else. You can also say Add GrpcClient and the GrpcClient… so in a server application, it will generate server code in a client application that generates client code, and that client code is actually built on top of HttpClient. So all the good stuff they’ve been doing all that insane optimization that’s been going on in HttpClient is fed through into the GrpcClient.

Okay, so you don’t have to start again from scratch, and wonder, “why is it not as fast as HTTP.” Because it’s using the same essentially, I guess it’s using HttpClient as a base class.

Yeah.

And just extending some things and changing some parameters, and doing all of his magic, but you can rely on the same base class.

And for things like authentication as well, this comes in really handy because gRPC has two modes of authentication. There’s connection level, basically, shared certificate or, you know, trusted so the client connects to the server, and the server says, “here’s my TLS certificate.” And the client can say, “was your certificate signed by the certificate authority that I know?” If it was then yes, “and by the way, his my certificate that says I am a machine inside the building, and I’m part of this network and I have a certificate.” And the server can validate that. And that has actually done - the client end is done by setting the certificate property on the HTTP client. At the server, it’s done by using the same certificate validation on Kestrel, the HTTP server, that you would use if you were doing certificate authentication on ASP. NET Core application.

And then you got token based authentication, which is per request, which is basically a bearer token.

Like JWT?

Not like it is a JWT. It is exactly, and it is just an authorization header. And so you can, you can set it, you can do it sort of through the gRPC API on the client. And you can say, “add this token to to every request.” But you can also add that authorization bearer space JWT token as a default header on the HTTP client underneath the gRPC client. And it still works. So it is, you know, it’s it’s proper is open systems, open standards. Everything is is built on top of the things you would expect it to be built on; haven’t gone and reinvented any wheels. And yet it is still bonkers performance. So yeah.

Excellent. I like that. It reminds me of so I have I’m going to quote someone who quoted someone else.

Okay. That was always good.

You never get it wrong if you do that, right. So there was an earlier episode in the show’s canon, I guess, where I had the great pleasure to talk with Phil hack. And he had said to Scott Hanselman that said, “okay, the Microsoft is a little like a an oil tanker. It’s turning slowly.”

Yes.

You know, it’s changing its behaviour slowly in the development area, you know, embracing open source and not trying to - You know, I mean people like throw around the the Bill Gates or was it Steve Balmer who said Linux is a cancer

I think it was Balmer who said Linux was a cancer. Bill Gates has the singular distinction of being the man who invented closed source.

Exactly.

And then made an absolute fortune from it.

And that’s, you know, that in itself is neither good nor bad.

Yeah.

Because if there was no such thing as closed source software, you and I wouldn’t make money.

But yeah, and this this idea of it this analogy of Microsoft being like a, like an oil rig or an old tanker just slowly turning.

Yeah.

And embracing the open source community and going yeah, okay. Because I mean, you have to look at I think it was Visual Studio 2005 when they made the decision to include jQuery, which meant they had to go and sign a whole bunch of licences.

The legal ramifications of putting jQuery and and it was always a good couple of minor releases behind because it had to go through whatever legal processes were there.

And that’s just a great example of them having to take that slow route. Because if they didn’t do everything correctly, and if maybe someone accidentally made it small change or a typo fix or something inside of that, that then changes the licence, perhaps.

Yeah.

So there’s lots to think about when you’re trying to - as a big organisation, even as a small organisation - adopt open source, like if you’re a three person outfit, and you want to work with say Angular, and then you spot a bug and you submit the fix. If you did it on works time does it does that fix belong to your company or? It’s complex.

I think not many people have the problems that Microsoft have. I think in terms of, because you look at the big tech companies as they, as they are seen now, for the most part, they’re not software companies.

Yes

Amazon is not a software company. Facebook is not a software company. Google is not really software. They all make software. And they all make things and share them. You know, Facebook does React, and Google’s done gRPC, and various sort of things that they’ve opened up for the world; and Go; and Dart; and whatever. But Microsoft make and sell software for a living.

Yes.

That’s what they do. And so when that is your business, the idea of going, “hey, maybe we should take a bunch of these people who we pay very, very well to write software and get them to write software that we’re going to give away for free.”

Yes.

“And not only we’re going to give it away free will to give the source code away for free with a licence that basically says, you can take this, change it and do what you want with it.” It’s nuts. And it did. It took them a very long time to get there.

You look back at the sort of the late 2000s and the early 2010s, 20-teens. And open source was kind of theres open JDK. Python has always been open source. Ruby’s always been open source. C++ there are multiple implementations, but you know, like, gcc and clang, was open source. I think Microsoft, I think they had to take .NET open source for it to remain relevant. But I think they deserve a lot of credit for doing such an amazingly good job of it. Because, they’ve done that they’ve sort of done that before ASP. NET MVC, right from the start was open source. But they wouldn’t accept pull requests.

Yes.

Because that is Microsoft code. We can’t have your code in Microsoft’s code, because we don’t, then your company might claim that it now owns 30% of Microsoft, particularly when you’re in the states where that’s the kind of thing that people go to court over. So to then just come out of the gates, “here you go, it’s on GitHub. We’re shutting down Codeplex its on GitHub. It’s MIT Licenced. And the first time you send us a pull request, you’ll get an automated email from a robot thing, saying, ‘Hey, could you just open this document up in DocuSign, and put a squiggle here that says, it’s okay for us to use your code and you’re relinquishing any ownership of it.’”

And that’s what’s really made the difference, because if it wasn’t for that, then we wouldn’t have had Ben Adams and the other contributors on Kestrel turning that into - I think it’s reliably in the top 10 fastest HTTP servers in the world. It’s doing millions and millions, 7 million requests per second now plain text. And yeah, some of that work was done by Microsoft people. But an awful lot of it was done by Ben Adams because he’s building an online multiplayer game, using HTTP, and he needed it to be fast. And so his work when, “Hey, you know what, if this is going to improve our game, then go for it.”

Yeah.

And there’s stuff in there that’s absolutely nuts. There was just and and then he kind of made Kestrel as fast as it was going to be for a while and he went, “right. What else can I do in the rest of the framework?” And he went and rolled up his sleeves and people go into CoreFX, and there’s people going, “I’m making current dictionary 90 times faster for this particular scenario.”

And it’s like, well, and yeah, it’s, I think, in open source terms, yeah. Okay. Maybe there’s still issues with other people doing open source .NET things. Microsoft are trying to help that with the .NET Foundation. It’s, again, it’s the oil tanker. It’s turning very, very slowly. But the fact that .NET Core itself is open source. And and of course Xamarin is also open source; and Mono is open source has meant the people, the contributor list on these things is huge. Its enormous and Eric Raymond said, “with enough pairs of eyes, all bugs are shallow.” And the stuff that’s been found and fixed over the last five years while they’ve been doing this, all the stuff that’s been kind of, “that’s a weird way of doing that. Why don’t you do it this way instead?”

Yeah.

We’ve got this amazing product now that we’ve built stuff on. And, and yeah, they didn’t bring WCF across. And there are two or three very good reasons for that: The WCF source code is terrifying. It’s not cross platform; unless you use SOAP and nobody’s doing SOAP anymore - you can’t even get SOAP libraries for Python 3.8 or, you know; SOAP is totes legacy. And they tried to actually publish the standard for NETTCP, for the encoding and decoding and how to do it and they said, “hey Java people you could make your own NETTCP things,” and Java people went, “er, no,” and they didn’t.

And then the third thing is, okay, sending SOAP messages backwards forwards. That bit of WCF is not particularly tied to .NET and not particularly tied to Windows. But a lot of the stuff that these big enterprise places are relying on: it’s not .NET, it’s windows. It’s Windows Authentication, it’s active directory and ADFS and LDAP. Distributed transactions relies on Microsoft’s distributed transaction coordinator. The queue stuff, yes, it’s asynchronous, and you can put it on a queue, but it’s MSNQ, who uses MSMQ anymore? It’s all RabbitMQ or its service bus or whatever. So WCF is a relic. And it’s - you can’t take it and put it on a cross platform environment and you can’t take it and dump it into a Kubernetes cluster, for example. Or it just it doesn’t fit in the modern world. And I think credit to Microsoft for not trying to replace it with a new thing that was like backwards compatible, they could have spent a lot of time building something that did, maybe 25% of what WCF did, and had a very similar API that would have made it easy to bring code across or whatever. And it would still, you know, it would have been .NET five talking to .NET five, and probably not backwards compatible to .NET everything. So it would still have been - but no, they went out and they looked at what the world was doing, and what the world was using, and the world was using gRPC and Microsoft went, “right. Let’s do that.” And then they looked at what the issues were with the current implementation of gRPC, and they fixed it.

And now it is, it’s just there.

It’s like an extra, one NuGet package reference, and it’s there. And you’re seeing this more and more as well as, you know. Swagger open API, they haven’t gone. This is how our API’s are going to document themselves, they’ve actually made changes .NET Core - ASP. NET Core three has got changes, to make it easier to generate Swagger documents without needing to put attributes all over the place. And they’ve changed action result, for example So you used to return an IActionResult of something. But if you wanted to return Not Found, then it was complicated. So people’s return types from their methods were not strongly typed. You wouldn’t know this returns a list of customers, this returns a list of orders. And they change that with .NET Core 2.0 when they introduced ActionResult, which is generic and so you can say, “this returns a result of a list of customers.” With implicit costs, so you just return a list of customers. But if you return not found, that’s okay, too. And they did that. So that nSwag and Swashbuckle had a bunch of additional metadata that they could reflect over and say, “Okay, so this is this API. And this is the URL. And these are the parameters. And this is the type of the parameters. And this is what it returns.” And you just put some extra bits of information in that says, “or it might return not found, or it might return forbidden.” And it could probably… my brain is currently in a place where I’m going, “Oh, you could write a Roslyn analyser it to do that.” Because I think I could watch a Roslyn analyser to replace myself.

Roslyn analyzer and voice recognition, and I will put every programmer in the world out of work, and we just go down to the beach.

Yeah.

That’d be good.

“Write me a CRM system,” just keep pressing Control and dot until a CRM sysem is built.

It would be the old Python thing of import game.

Yeah, but in bulk. Have you used Intellicode yet?

Not yet.

I turned it on. It’s early days, let’s put it that way. Sometimes it’s really, really clever. It does things that are really clever. And he kind of like, “woah. I just realised what you’re doing.” I had a thing. I was in some test code. And I had quite a lot of numbered things, mostly going 1, 2, 3, 4, 5. And then I moved across and I went 1, and they weren’t in line. But when I pressed down, it jumped to the next number on that line, and I just like replace that with return and download it. And it was doing this and it offers completions where you’re just kind of going, “how could you possibly know that?” But then at the same time, if you’ve got, if you got two methods that were private and you change them to public, then it immediately puts its green squiggles all over all your other private methods going, “I am suggesting you should probably refactor these public as well,” and you’re like, “no just because I didn’t once doesn’t mean, or I did it twice. That doesn’t mean you’re doing all the things!”

But yeah, they’ll get there. Yeah, why am I talking about IntelliCode? And Roslyn? That’s right. Yeah, you’ve probably run a Roslyn analyser to plough through your control methods and check to see what returns are in there, and then automatically generate the attribute that that says that stuff as well. But yeah, that’s an open standard. And they are building on these open standards, but they’re also doing the work to make them feel native to .NET and natural for .NET developers. I think that’s important. And with a great developer experience in Visual Studio.

Cuz I like bouncing around on the command line and having tabbed terminals and 50 of them open and all this sort of stuff. But lots of developers, right click and do this, and file new do that. And they’ve made that work. Just as well.

Yeah, exactly. Right. There’s the argument for, “I’m going to learn the arcane command to,” - so back in the .NET 2.0 days, when I was learning .NET, one of the things that I did was it everything from the command line, so it was Notepad, new file, CSC file, and yeah, a whole bunch of arguments. And then eventually, an EXE pops out the other end.

Yes, hand crafted csproj files.

Or I can hit f5. And it does it all for me.

Yeah. Yeah.

You know, it’s there’s an argument for knowing how the tool works. And there’s an argument for developer productivity.

Yes, yeah. Like the command line stuff so .NET commands: dotnet new, dotnet sln add. But to add a NuGet package, I will right click on references and say, “manage NuGet packages,” and use the nice GUI thing. Because I can never, unless it’s something that you use - if it’s Newtonsoft.Json, then yes, you know what that is and it will get the latest version. But if it’s message pack something or gRPC something, you’re kind of going, “I can’t remember what order it’s in.” And so yeah, there’s a very good argument for both views. And God help me if I ever have to write code without completions.

Yes.

Of any kind. It’s, yeah, it’s not going to go well. I my defence, it’s much more complicated now than it was 30 years ago.

Exactly. Exactly. And you know, again, the mental gymnastics required to remember the entirety of your code base, and all of the supporting libraries, and everything that’s involved in your app, and that your app is ever going to touch; versus, “I need to implement a bug fix, and it needs to not throw an exception here.”

Yeah, exactly. Yes.

So you know, I was doing C in vi it back in 1989. And I don’t, I couldn’t say for sure, but I don’t know how big C standard library was in 1989. But I know that I remember about 20 functions from it. And I think I was doing pretty much everything, including the curses stuff. With yes, strconf, strcopy, and malloc and free - if you are having a good day. Yeah, it was a lot, lot simpler. And now we’ve got .NET framework. Yeah, hundreds of classes, thousands of methods. You can’t remember all that.

Exactly right. Exactly. So it just makes it easier just to have all of these tools.

Yes.