Episode 17 - ASP.NET Core's Middleware Pipeline with Andrew Lock

So the first thing I want to say is thank you ever so much, Andrew, for donating some time to the podcast. It’s really kind of you to do that, and I really appreciate everyone who has said that they want to be on this.

Oh no, dude. You’re very welcome. Thanks for having me on.

Thank you very much. So, for the very small number of listeners who might not know who you are, I was wondering, could you give us a brief introduction to yourself? Maybe talk about some of the things that you’ve done, or where people might know you from?

Sure, yeah. People probably mostly know me from my blog. I started that about two and a half years ago now, and that’s been basically just about ASP.NET Core.

I am currently a software developer at a company in London called Elevate Direct. I’m living in Plymouth, so I work remotely. My job is basically on the back-end .NET services and APIs, and at the moment I’m mostly converting ASP.NET stuff to ASP.NET Core.

So maybe, if you have time, we could talk about the benefits and pitfalls of converting from .NET Framework to .NET Core, if that’s okay with you?

Sure.

Fantastic. Okay, I’ll make a note to ask you about that later, because I’m sure I’m going to forget.

So, you’ve been writing the blog. Is it specifically about ASP.NET Core, or is it more ASP.NET Core and a few .NET Core-y things?

Yeah, everything’s around ASP.NET Core, but there are .NET Core bits in there, and there are some C# bits in there that I run into. It’s pretty much things I’ve run into in my normal walks of life: doing my job, and bits on the side. So it’s anything that I run into whilst doing that.

That was going to be one of my questions, because a lot of your blog posts are incredibly useful. They come across as very much, “I’ve had this problem today, and here’s how I solved it.” Not to dumb down what you’ve written, but how you’ve written it is both incredibly detailed and really accessible, if that makes sense.

So when I was first learning about Docker and putting ASP.NET Core inside of Docker, I naturally went straight to your site, and looked at a few posts by Hanselman. You have a wonderful series all about, “hey, I want to take this thing and put it inside of Docker, and here’s how I capture all the csproj files and capture the directories,” which is really useful. I guess I want to say thank you for that, because it saved me a bit of time.

Well, I’m glad it’s saved people time, because it pretty much has been that. When I started the blog, it was really just me trying to learn the framework, because I started around the RC2 period, before 1.0 was released, and the documentation was a little bit spotty at that point. The easiest way I found to learn it was to dive into the source code, so I was doing deep-dive posts at that point. Then, as I started using it more, the documentation got as brilliant as it is now, so I didn’t need to do that so much.

But pretty much, yeah, I’ll be working along at something, then I’ll get stuck, and I’ll Google it or have to look in the source code to figure things out. Whenever I do something that I think wasn’t easy, I’ll make a note of it, and that’ll be the subject for a post next time, like you say. If it takes me an hour to figure something out, then I think I can put it in a post and save someone half that time, at least.

You know, not to blow my own horn, but that was the original idea for my .NET Core blog.

Yeah.

But I don’t think it really went anywhere. I mean, I have written a lot of blog posts, for almost as long as you’ve been writing, but my blog posts tend to be around the three to four thousand word mark, which is no good for a technical blog. People want to hit it, get the source code, and leave.

I think that’s the difference. There is a place for those posts, and they’re very interesting. With those, you can nestle down with your cup of tea and work your way through. It’s the difference between “I’m just trying to solve a problem,” as opposed to “look at this interesting view of a problem.”

It’s interesting that you mentioned the documentation. As we’re recording, about a week and a half ago I interviewed Steve Smith, who actually wrote most of the initial documentation for .NET Core, ASP.NET Core, and I think a little bit for EF Core.

I’ve certainly seen his avatar on the docs site.

Yeah. A lot of the first six to eight months of his knowledge of ASP.NET Core, at least, was figuring out how he would write the documentation. So it’s interesting that you’ve said that, because it’s the same with anything: when you first get hold of some new technology, the documentation is not going to be there, because we’re developers, and we don’t write good documentation, do we?

Exactly.

I mean, if my boss is listening, obviously I write loads of really good documentation.

Yeah. I think as well, because things were changing so much at the start, that was one of the big problems, especially in RC1 and RC2, before you even got to 1.0. They were going back and forth between project.json and csproj, so there was a big mix of what was going on.

I feel like now there’s a very concerted effort to have the documentation up to par for when they actually release things. They’re working on the preview documentation before they’ve released 2.2, you know. So I feel like the docs are in a really good place now.

There’s a reason for the old adage of “wait until version two exists,” and it’s not just for bug fixes. It’s also for, like you say, documentation.

It’s true, yeah.

You’ve been writing a lot of deep dives, looking into the source code, and writing some incredibly useful blog posts. But obviously you also have a book out at the moment as well: the ASP.NET Core in Action book.

I do.

I was wondering, could you tell the listeners a little bit about that?

Sure. I started that book about two years ago now, so the book actually started pretty much around the 1.0 time, which was challenging given everything was changing fast. It had to be rewritten several times to keep up.

It’s intended for someone who knows C# but doesn’t necessarily know a lot about web programming, so it could be mobile or desktop developers. Obviously, if you’re an ASP.NET developer already, then it’s a big advantage. It covers all the basics of an ASP.NET Core app: configuration, dependency injection, and the middleware pipeline. Later on, it goes into some of the more complex bits like security, building custom components, and things like that.

I do have to say that I got a copy as soon as I noticed it was out on MEAP (Manning Early Access Program). Because it was published with Manning, there’s this early access programme that they have, isn’t there?

Yeah, so you can get the book as it’s actually being written. You can see the previews and give feedback while it’s being written, which is very useful.

I know that I’m pretty terrible at giving feedback, so I held off on getting the MEAP, if I’m honest.

I’ve had a copy of the book for a few months now, and unfortunately it’s one of those that is really well written and easy to lose myself in. But because it sits on my desk, it only ever gets looked at when, “oh, this thing’s compiling and it’s going to take forever. Okay, I’m going to learn a little bit more about ASP.NET Core.” Or, “well, this operation’s taking a while. It’s taking a while to do this Entity Framework migration. Right, let’s get the book out and learn a little bit more.”

It’s got a few pages for you to get through.

Yeah, yeah. But no, it’s really good. I really like it.

Thank you.

You’re very welcome. I would definitely recommend it to anyone who’s listening. I’ll have a link in the show notes if anyone wants to check it out, because it’s really useful. There’s a lot in there. I don’t want to say there’s stuff in there that I didn’t know about, but obviously there are things in there I didn’t know about. I’ve not done the deep dives into the source code, so…

Let’s good to hear.

One of the things that I find is not difficult, but a big change for people when they’re coming to ASP.NET Core from ASP.NET, is this idea of the middleware pipeline. Since you’ve written the book, I was wondering whether you could go through a little bit about how the pipeline works, what it is, and what middleware is. Obviously I know going into this that explaining it without pictures is going to be a little difficult, so I feel like I’m putting you on the spot.

It can be tricky. So, the middleware pipeline. A lot of people come from ASP.NET, where the original process for handling requests was using HTTP handlers and HTTP modules. That was the old-school ASP.NET lifecycle. A bit later on, Microsoft introduced OWIN, which was an attempt to separate IIS away from your application, and OWIN was really the forerunner to ASP.NET Core. So if you’re familiar with OWIN, then ASP.NET Core is essentially the same.

A piece of middleware is essentially a function that has two inputs. It’s a function that takes an HttpContext, which has all the request details: the headers, the body, the URL, things like that. The second input is a pointer to the next piece of middleware, so each middleware knows which piece of middleware it’s going to call next.

When a request comes to your app, it calls the first piece of middleware and passes it an HttpContext. That middleware does something with the request, which could be anything, and then it calls the next one. That calls the next one, and that calls the next one, so you have this big chain of function calls. Eventually some piece of middleware will handle the request. It’ll say, “I know what to do with this,” and it’ll generate a response. That response will then pass back through the function calls, essentially, all the way back out to the user.

Each piece of middleware can do several things. You could have a static file middleware, which would recognise requests for static files, like CSS files or JavaScript files, and it will just return that file as the response. A middleware could also essentially do nothing. If it doesn’t know what to do with a request, it can just pass the request on to the next piece of middleware, and that’s what it has to do. Somewhere down the line, a later piece of middleware will return a response. If none of the middleware can handle it, then there’s a special piece of middleware at the end which will return a 404 response. So eventually something will come back down through the pipeline.

That’s pretty much it. Your app is basically plugging together these different pieces of middleware to create your application.

In that case, there’s no one middleware to rule them all, I guess. There’s no one piece of middleware that does everything.

No, exactly. They’re designed to be relatively small, self-contained pieces of middleware. So you’d have a static file middleware. You’d maybe have a security headers middleware, which adds content-sniff headers and things like that. You could have a piece of middleware which does authentication for the request, so it’ll look for an Authorization header and set the user for the request.

Then the big one is the MVC middleware, which is what encompasses the whole of MVC in ASP.NET Core. That will route the request to a specific controller and handle the request like that. But the MVC middleware itself isn’t required. You can create little services that don’t have the MVC middleware, and just handle other things instead.

So I’m imagining the ASP.NET Core middleware as almost like a supply chain: you have a conveyor belt and maybe five or six different people who are each doing something. Let’s say we’re passing a motherboard down a supply chain, and one person’s job is to solder, I don’t know, the CPU housing onto the motherboard, and then pass it on. The next person solders on the RAM housing, and the next person puts on a CMOS or a CR, whatever the… I can’t remember the acronym now, but the battery that holds the BIOS details. What you’re saying is that each person, or each thing along that supply chain, only does one job, I guess.

Exactly. Yeah, that’s a great analogy. It’s exactly like that. It’s a supply chain that passes all the way through, till someone goes, “right, that’s it, it’s done, we’re good with this.” Then they pass it back down the supply chain, so everyone that’s seen it before gets another chance to see the final response. They can potentially take some action based on that response as well.

So if my request is going down this pipeline, and it gets to a point where someone says, “I have a response that I can send out,” the response then has to go back up in the opposite direction, I guess, back to the origin.

Exactly. Essentially it passes back down the pipeline, as it were, so everything that’s seen it before gets to see it again, in some respects.

You’re working with streams, so you can’t necessarily modify the response necessarily. In some cases you can, but because of the way streams work under the hood, you may have already started sending data back to the client. You do get to see that response coming back through, though.

Okay, so perhaps I could have some logging middleware, for instance, that can log the request as it comes in, and let something further down the pipeline deal with generating the request… sorry, generating a response. Then, as that response comes back up, my logging middleware can say, “yes, I’ve seen that we’ve generated a response, and here is the response we generated. I’ll store that, or some details about it, on disk,” and then let the response carry on through.

Exactly, you can do exactly that. On the logging side, ASP.NET Core already includes a lot of logging, so it will already record metrics and things for you. If you want to actually record the response generated, you’ll again have to do some playing with streams, because you can’t necessarily capture the output as it’s streamed out. But in principle, that is exactly right.

So you mentioned security headers. I do know that you and I both have… I remember I wrote a little blog post about adding OWASP headers to ASP.NET Core, and one of the comments was you saying, “hey, great minds think alike.”

Yeah, exactly. It’s one of those things that you run into relatively early, I think. Yeah, it does show great minds think alike.

I guess that’s one of the things that a middleware item is perfect for, in that it can make small, incremental changes: “I can change this one thing, and then just pass it on.”

Exactly.

What happens if my middleware component, say, is working away and something falls over? Can my middleware component raise an error? Is that caught by the middleware pipeline?

Yeah. You can think of each middleware as a function, so when you call the next middleware, you’re essentially calling the rest of the pipeline essentially. That means you can just put a try-catch around that. If a later piece of middleware throws an exception, you can catch that exception and handle it any way you want. You could log it as an exception and carry on.

You could do what the exception handling middleware, which is built into ASP.NET Core, does, which allows you to re-execute: do something different, and then execute the pipeline again. So you can have these branching structures based on things like that. Essentially it’s all C# code, which is one of the benefits, so you can do whatever you want.

Okay. That makes me think that perhaps there’s scope to say: I have some middleware, and say the next thing in the pipeline is MVC. If MVC raises an error, I can catch that and not allow, I guess, the global middleware system to catch it, and then I can do something with it. Is that something that can happen?

Totally, you can totally do that. Although there’s already a piece of middleware whose sole job is to do that, so it would make sense to leverage what’s already been built. But that is one hundred percent something you could do, yes.

Does that mean, then, that my middleware can potentially report on when a piece of middleware further down the pipeline has fallen over, if nothing else has reported on it, I guess?

Yeah, yeah, totally. If you want a response, then you could do that. Depending on how you’ve configured your application, and depending on the order of the middleware that you’ve added, that may or may not be possible. It’s common to add an exception handling middleware, but you typically add it very early in the pipeline, which means it can catch an exception for anything that happens later.

So you’ve brought up a key thing there, I guess: the order of the middleware items.

Designing your application is very much choosing the order in which you connect these pieces. The things that are the most important, and that you want to affect the most requests, have to go early in the pipeline. Things that you want to fail fast, you want to have early in the pipeline too, because that means that all requests will go through them.

In that respect, then, would it make sense to put any middleware after MVC?

Generally not. It depends, but generally speaking, because of the way the MVC routing middleware works, it will normally try to match to a controller. If it can’t match to a controller, that probably means you made a mistake, so you wouldn’t want it to be calling other middleware.

There is a bonus piece of middleware which is added to the end of all pipelines automatically by ASP.NET Core, which just generates a 404. It says, “if you haven’t been handled up to this point, just generate a 404 Not Found error and return that.” So it’s pretty unusual to have anything after the MVC middleware.

So, because I can think of these middleware items as essentially just functions, that obviously means I can create my own, doesn’t it?

Totally, yeah. It’s really simple. You can create literally just an inline lambda function, which acts as a piece of middleware, in your Startup’s Configure method. Or, if you’re creating anything that’s doing anything non-trivial, then you can create a middleware class to modularise it, which is much more common.

So you said MVC. What if I want to have a Web API? Do I have to add a second piece of middleware?

In ASP.NET Core, MVC and Web API are the same thing now. It’s all one stack. In the previous version, yeah, MVC was for using Razor and generating pages, and Web API was purely for APIs. There’s not that separation anymore. You can still have API controllers, and they return JSON or XML or anything else you want. You can also have “MVC controllers,” in inverted commas, that use Razor to generate views. But they are all part of the same infrastructure, so it is all just part of the MVC middleware.

That makes everything a little simpler, I guess, because, as you say, in ASP.NET you would have maybe a project or a bunch of controllers that were Web API controllers, and a selection of controllers that were MVC controllers, and never the twain shall meet.

Except they did, and you ended up with namespace clashes, and it was horrible. Yes.

So what about things like response minification? Let’s say my app calls straight down to MVC, and it generates a view that it’s going to return. Can I minify that on the way out? I’m trying to imagine where I would put that, because I don’t want to minify on the way in, I have to do it on the way out. But I have to add it into the pipeline, and it’s got this bi-directional U shape, I guess.

Yes. Essentially you’d need to insert that minification middleware somewhere before the middleware that’s generating the response. If you inserted it before the MVC middleware, then the response would return back through your minification middleware, so it would be able to modify that response, assuming it hasn’t started streaming yet.

So as long as it hasn’t started streaming, then the single middleware item, the single middleware class or single middleware lambda, can do something on the way in, or on the way out, or both, I guess.

Exactly, yes.

This is all handled in the Startup, isn’t it?

Yeah, this is all in Startup.Configure. That’s where you define your middleware… sorry, that’s the structure of your application.

So is this talking directly to Kestrel? For the listeners, that’s the web server that ASP.NET Core can run on, but it doesn’t have to. Is that configuring Kestrel, or is this configuring something after Kestrel?

Yeah, this is the bit after Kestrel. Kestrel is handling the raw HTTP bit. It takes the request, breaks it out, finds the headers, works it all out: handling the protocol side. The middleware is more your actual application. Kestrel calls your first middleware, so you can think of your application as being primarily your middleware.

I’ve actually forgotten what it was I was supposed to ask you afterwards. Remember I said, “oh, I’d better remember that for later”? I’ve completely forgotten.

I’ve forgotten too, yeah. When I started, I was intending that the book was maybe just going to be for ASP.NET developers who were moving to ASP.NET Core, because obviously that was the person I was, so it was easy from that point.

I’ve remembered what it was. It was converting ASP.NET Framework to ASP.NET Core.

Yes, of course. Why don’t we continue in the direction we were going when you were talking about the book, and how it was originally for ASP.NET to ASP.NET Core, and then we’ll loop back around. I’ll make a note of it now.

Okay. So the book wasn’t intended for that. When I started the blog, I was essentially writing it for future me, so it was written for someone in my situation: someone who knew ASP.NET, had heard about this ASP.NET Core thing, and wondered what all the fuss was about. That’s why a lot of the posts are written with the assumption that you already know ASP.NET.

That was a little bit narrow for the book, in terms of scope and audience. So we’ve opened it up a bit more in the book, so that it accommodates people who don’t know ASP.NET, or much web programming in general.

So let’s say I’m a C# developer who’s been working in Xamarin, for instance. I’ve created a Xamarin app, and now I’m thinking, “I need to make a server-side Web API for my app to talk to.” Why I’ve waited until I’ve published the app, I don’t know, but let’s say that’s the situation. So this is someone who can get some information from the book and go, “right, now I understand ASP.NET Core,” without having to understand ASP.NET?

Exactly, that’s the intention. But if you already know ASP.NET, then there’s the contrasting between the two, how the middleware pipeline is new, and things like that. So it does cover both sides of it. You don’t have to know ASP.NET now.

How about we talk about converting ASP.NET to ASP.NET Core? Could you give any benefits, pitfalls, potential gotchas, tips, anything like that? Other than, obviously, buy the book and read the blog.

I mean, the overall message is: don’t bother doing it unless you need to. ASP.NET Core has a lot of nice features, and the architecture feels a lot cleaner. It feels like you can get a lot further. But fundamentally, rewriting from ASP.NET Framework to ASP.NET Core in itself isn’t going to be worth it for you.

The main benefits, and the main reasons, are if you’re wanting to change how you’re hosting the application. In our case, we had a lot of Windows-based servers, which were just harder to manage than Linux-based servers. Especially if you’re already running applications on Linux, it can make sense to consolidate on one operating system in that respect. That was the main driving force behind us rewriting them at our company.

For the most part, it’s been pretty easy, to be honest. The applications have been using Web API, basically, and converting from ASP.NET Web API to ASP.NET Core Web API is pretty trivial. There are some small gotchas that can trip you up. Things like posting JSON to ASP.NET Core controllers: you have to put the [FromBody] attribute on in order for it to be deserialised correctly. Or you have to use the new [ApiController] attribute, which was added in .NET Core 2.1, which handles that for you. So there are little differences like this which will trip you up. But if you’ve got a basic, simple MVC application, then it might not be that hard.

Your biggest problem will be dependencies. If you’re dependent on NuGet packages which are .NET Framework only, or Windows-only packages, then you’ll run into difficulties. But at this stage, with .NET Standard 2.0 out, and I know you’ve had a podcast on that already, it can really not be that difficult now.

So if you were giving a recommendation for someone to start using ASP.NET Core, would you recommend a greenfield, new project, rather than taking an existing one and moving it over?

Yeah, definitely. I think that’s definitely the easiest approach. You’ll be able to start with ASP.NET Core best practices and the common idioms, and yeah, I would definitely recommend that.

Would you recommend people… well, I guess it would be better to experiment on your own time, rather than costing the company that you work for, if you have that choice.

I mean, like I say, it’s hard to make a business case for rewriting applications to essentially deliver the same value, just with a different stack. That’s rarely worthwhile, unless you can actually get some benefit from doing it. In our case, it was rewriting relatively small services, so that we could deploy them in Docker, deploy them to Kubernetes and things, and manage them that way, rather than the previous bespoke management we were using for the ASP.NET Framework applications.

I’m about to use a buzzword here, which means that we’ll both appear on some LinkedIn list, I’m sure. With ASP.NET Core, I don’t want to say is it easier, but can you lean more towards microservices? Or are you limited to “here is your monolithic app, and if you want to cut it up into small pieces, then you haven’t got a choice”? Or is it come as you please: can you do microservices, monoliths, that type of thing?

It’s the latter. You can build whatever application you like with it. It does make it a lot easier to build small services, for whatever level of small you want to use. You only have to add the components and libraries that you want to add, so it’s an additive process, as opposed to a subtractive one. ASP.NET gave you everything, and you always had everything, whether you chose to use it or not. Whereas ASP.NET Core says, “you choose a bit from there, you choose a bit from there, and you add it all together to get what you want.” Which means you can keep them small, if that’s what you need to do.

I do like that, I’ve got to say. It has caused a few issues, mainly with myself, where I go, “but why can’t I call this API?” Then I realise, “oh, I’ve got to drag that NuGet package in.”

Yeah.

Like you say, it’s those pitfalls, isn’t it?

It is. Things have got a bit better at the moment, though. If you start now, say with ASP.NET Core 2.1, you can add the Microsoft.AspNetCore.App NuGet metapackage, which essentially brings in all of the libraries that you might want, which make up the framework. That doesn’t mean that you have to use everything. It just means IntelliSense lights up for you, basically. You can still see everything that you could have, but you only have to use the things that you want.

The question that I didn’t ask earlier on is: is ASP.NET Core a .NET Core technology, or can I use it with .NET Framework?

You can use it with .NET Framework. ASP.NET Core is decoupled from that. I personally haven’t, so I can’t really comment on it, but I feel like most of the impetus is with .NET Core. Certainly if you’re starting a greenfield application, I’d definitely recommend building on .NET Core. .NET Framework is going to stay there, and it’s going to be supported, but all of the momentum is with .NET Core at the moment. So it makes sense to stick to that if you can.

I can speak from experience in that I know some people who are doing ASP.NET Core on the back of .NET Framework 4.5, I believe, to keep the .NET Standard version low enough that they have a wide enough target area. But this is a project which had started, I think, a year and a half, maybe two years ago. So at the very birth of it, somebody had said, “hey, why don’t we use this new technology?” They were like, “well, we don’t want to learn two new technologies.” But like you say, it’s completely decoupled, isn’t it? So you can mix and match if you really feel like you need to.

Yeah, you can. I’d recommend not using it, especially as .NET Core now has the… I think it’s called the Windows Compatibility Pack, or something like that. So you can still use Windows-specific APIs, even if you’re using .NET Core, which is itself cross-platform. You can get the best of both worlds in that respect.

Does ASP.NET Core, because it’s cross-plat I guess it’s decoupled from .NET Core, but it enables hooks into .NET Core and makes it cross-platform, I guess?

Yeah. Most of the packages are .NET Standard packages, so it runs on any platform which supports the required level of .NET Standard. That’s how the framework itself is cross-platform, in that respect. There are packages which are also part of the framework which are specific to .NET Core. As you say, they allow additional hooks into various features which are .NET Core only, and things like that. So, as you say, you can get the best of both worlds in that respect. If you need to use .NET Framework for some reason, you can. But otherwise, yeah, you can use .NET Core.

Does that mean that it leans into Docker land, or container land, quite easily then, since it is cross-platform and all of these lovely things?

Totally. That’s one of the big selling points for .NET Core: how easily it plays with Linux and Mac.

Before I was working for this company, I was working for a company that worked entirely on Macs, so I spent my life living in Visual Studio inside of a VM in Parallels, while using a Mac generally. It was so much nicer to be able to natively build ASP.NET Core applications on your own hardware, rather than living in a VM. But Docker is definitely one of the selling points for it.

There’s an episode where I talk with Dave Rael from the Developer On Fire podcast, and we eventually ended up just talking about command line interfaces, and how wonderful the .NET Core, ASP.NET Core, and EF Core .NET command line tools are. I’d said that when .NET Core first came out, I was sitting in front of a friend of mine on my MacBook Air, and I built something on the command line. I literally pulled the USB memory stick out, jammed it into his machine, and it booted, and he didn’t even have anything installed, which was…

Magical.

It is, it’s magic. It’s complete magic.

Who would have thought we could have nice things like this in .NET land?

Well, it just took a little while to get there, that’s all.

All that remains to say, I guess, is thank you for being on the show. It’s been wonderful to have this chat with you, and hopefully the listeners will get a lot out of this. Maybe you’ll get a few extra book sales, I don’t know.

No, it’s been great. It’s been great to chat to you, Jamie. Thank you.

Brilliant. If the listeners want to learn more about you, maybe connect with you online, or learn about the book, where is the best place for them to go?

My blog’s probably the best bet, which is andrewlock.net. Otherwise, I’m on Twitter at @andrewlocknet. Yeah, those are probably the best places.

Okay, cool. I’ll make sure to put some links to those in the show notes, and I’ll make sure to put a link to the book on Manning Press, because it’s Manning Press or Manning Publishing, I’m not sure. It’s one of those two.

That’s great, thanks.

It’s definitely worth having a look, because you get some preview sections, don’t you? Even if folks just look through those to get an idea of the stuff that you go into. It’s really, really good, I have to say.

Great, thanks.

You’re very welcome. Like I say, thank you very much for being on the podcast. It’s been excellent connecting with you today, and learning a little bit more about ASP.NET Core and the middleware pipeline, and how it all fits together. It’s been wonderful.

Thank you very much. It’s been great fun.