WEBVTT 1 00:00:00.080 --> 00:00:04.200 Welcome listener to this custom tailored deep dive. Today we 2 00:00:04.240 --> 00:00:06.080 are well, we're doing a bit of demolition. 3 00:00:06.240 --> 00:00:07.240 Yeah, quite a bit actual. 4 00:00:07.719 --> 00:00:09.960 So, if you were building an enterprise web app on 5 00:00:10.039 --> 00:00:13.679 the Microsoft Stack anytime over say a sixteen year period, 6 00:00:14.439 --> 00:00:18.320 you are basically living in this massive, incredibly luxurious mansion. 7 00:00:18.399 --> 00:00:20.399 Oh absolutely, it had everything. 8 00:00:20.199 --> 00:00:25.280 Literally everything, Intricate security systems, elaborate plumbing, pre built rooms 9 00:00:25.320 --> 00:00:28.280 for any feature you could ever possibly want. But there 10 00:00:28.399 --> 00:00:32.039 was a catch, a huge catch. Yeah, it was completely 11 00:00:32.079 --> 00:00:35.320 hopelessly bolted to the ground. You could not move this house, right. 12 00:00:35.359 --> 00:00:38.560 The plumbing was like physically welded to the city's main 13 00:00:38.640 --> 00:00:43.719 water line, which in this case was Windows Internet Information Services. 14 00:00:43.840 --> 00:00:46.920 Or IA exactly. So if you wanted just to pick 15 00:00:47.000 --> 00:00:50.039 up your application and move it to a cheaper Linux server, 16 00:00:50.560 --> 00:00:53.200 good luck. You'd have to rip the entire city's pipe 17 00:00:53.240 --> 00:00:54.159 system out of the ground of. 18 00:00:54.159 --> 00:00:55.359 It, which is obviously impossible. 19 00:00:55.640 --> 00:00:59.280 Right. So today our mission is to unpack the mechanics, 20 00:00:59.359 --> 00:01:03.039 the history, and the architecture of the moment Microsoft decided 21 00:01:03.039 --> 00:01:06.239 to just dynamite that mansion. We're looking at how they 22 00:01:06.280 --> 00:01:10.200 rebuilt modern web architecture from the ground up with ASP 23 00:01:10.280 --> 00:01:10.920 dot net. 24 00:01:10.760 --> 00:01:14.159 Core, and we're using Andrew Locke's book asp Net Core 25 00:01:14.200 --> 00:01:16.159 in Action as our primary source material for this. 26 00:01:16.359 --> 00:01:19.359 Yes we are. But strangely enough, to really understand how 27 00:01:19.359 --> 00:01:22.359 they pulled this off, we have to start by looking 28 00:01:22.400 --> 00:01:25.200 at an illustration from eighteen oh two. 29 00:01:25.400 --> 00:01:26.599 Yeah, the cover of the book. 30 00:01:26.719 --> 00:01:29.040 It's so good, it's wild. It's a picture of an 31 00:01:29.079 --> 00:01:30.359 ottoman admirle right. 32 00:01:30.280 --> 00:01:33.159 A capuota on pasha, and he's looking incredibly regal. He's 33 00:01:33.200 --> 00:01:35.439 got this towering hat, a fur lined robe. I mean, 34 00:01:35.480 --> 00:01:39.599 it is a massive departure from your standard minimalist tech 35 00:01:39.640 --> 00:01:41.120 book esthetic, definitely. 36 00:01:41.519 --> 00:01:43.560 But the story of how that specific piece of art 37 00:01:43.640 --> 00:01:47.959 ended up on an asp net manual, it perfectly captures 38 00:01:48.000 --> 00:01:50.400 the whole philosophical shift Microsoft ad to make. 39 00:01:50.640 --> 00:01:51.200 It really does. 40 00:01:51.239 --> 00:01:54.640 So. An editor from Manning Publications actually found this antique 41 00:01:54.680 --> 00:01:57.680 illustration at a flea market in New York City. 42 00:01:57.519 --> 00:01:59.079 Just sitting there at flea market, Cort. 43 00:01:59.359 --> 00:01:59.640 Yeah. 44 00:02:00.040 --> 00:02:02.280 The editor didn't have the cash on hand to buy it, 45 00:02:02.560 --> 00:02:05.120 and the seller was actually flying back to Anchor a 46 00:02:05.400 --> 00:02:07.000 Turkey that very night, so. 47 00:02:06.959 --> 00:02:09.360 They couldn't just do it the next day, right, So. 48 00:02:09.319 --> 00:02:11.879 They made a handshake deal. The seller just handed over 49 00:02:11.879 --> 00:02:14.960 the portfolio based purely on a promise that the funds 50 00:02:14.960 --> 00:02:16.240 would be wired the next morning. 51 00:02:16.319 --> 00:02:21.639 I mean that is just that transaction relied entirely on trust, right, trust, 52 00:02:21.759 --> 00:02:24.759 modularity and this incredible cross border exchange. 53 00:02:24.960 --> 00:02:28.039 Yeah, the seller trusted a completely disparate system to deliver 54 00:02:28.080 --> 00:02:28.479 the results. 55 00:02:28.520 --> 00:02:32.120 And the funny thing is Microsoft's original ASP dot net 56 00:02:32.439 --> 00:02:34.520 operated in the exact opposite. 57 00:02:34.039 --> 00:02:35.319 Way, completely the opposite. 58 00:02:35.400 --> 00:02:39.719 It was this closed, deeply entangled ecosystem, and the core 59 00:02:39.800 --> 00:02:45.439 of the problem rested on one single immovable dependency, System 60 00:02:45.479 --> 00:02:46.639 dot web dot DL. 61 00:02:46.759 --> 00:02:50.000 Yeah, System dot web dot DLL. That specific file was 62 00:02:50.039 --> 00:02:52.800 the concrete foundation of that old mansion you were talking about, right. 63 00:02:52.840 --> 00:02:55.680 It wasn't just like a library your code referenced. It 64 00:02:55.719 --> 00:02:58.759 was woven directly into the broader dot net framework. 65 00:02:58.360 --> 00:03:00.319 Which was baked right into Windows itself. 66 00:03:00.159 --> 00:03:03.000 Exactly deep into the Windows Operating System kernel. 67 00:03:03.159 --> 00:03:06.759 And so if system dot web dot do well is 68 00:03:06.800 --> 00:03:10.560 tied to the OS kernel, that means updating your web 69 00:03:10.599 --> 00:03:14.080 framework is practically impossible without updating Windows itself. 70 00:03:14.159 --> 00:03:15.680 Yeah, it was an absolute nightmare. 71 00:03:15.800 --> 00:03:18.400 I can't even imagine a developer couldn't just you know, 72 00:03:18.599 --> 00:03:21.680 patch a minor web routing bug without forcing the whole 73 00:03:21.759 --> 00:03:25.080 enterprise to do a massive system wide Windows regression test. 74 00:03:25.240 --> 00:03:29.639 Right, So release cycles routinely took years years, Yeah, because 75 00:03:29.680 --> 00:03:33.439 the framework had to maintain backward compatibility with over a 76 00:03:33.560 --> 00:03:37.080 decade of legacy enterprise features. And worse than that, it 77 00:03:37.159 --> 00:03:41.039 aggressively locked out developers working on macOS or Linux machine. 78 00:03:41.080 --> 00:03:43.400 You just you couldn't participate in the ASP dot and 79 00:03:43.479 --> 00:03:45.240 an ecosystem natively at all. 80 00:03:45.280 --> 00:03:46.039 You really couldn't. 81 00:03:46.159 --> 00:03:49.159 So the paradigm shift finally happened when Microsoft introduced dot 82 00:03:49.199 --> 00:03:52.280 net Core as an entirely separate open source runtime. 83 00:03:52.400 --> 00:03:54.199 They finally decoupled it exactly. 84 00:03:54.240 --> 00:03:57.360 They decoupled the web framework from the operating system entirely. 85 00:03:57.680 --> 00:04:01.319 It finally delivered on that compile once on anywhere promise. 86 00:04:01.039 --> 00:04:03.319 So a developer could finally sit on a Mac, write 87 00:04:03.319 --> 00:04:06.360 some c shark code, build it, and deploy those exact 88 00:04:06.400 --> 00:04:09.879 same binaries too, like a nUbuntu server in the cloud. 89 00:04:09.840 --> 00:04:13.560 Yep and breaking those dependencies didn't just make it cortable, 90 00:04:13.639 --> 00:04:16.120 it opened the door for staggering performance games. 91 00:04:16.199 --> 00:04:18.199 Oh the speed, let's talk about the speed. 92 00:04:18.319 --> 00:04:18.639 Yeah. 93 00:04:18.720 --> 00:04:22.680 Microsoft introduced a brand new built in cross platform web 94 00:04:22.680 --> 00:04:23.879 server called Kestrel. 95 00:04:24.000 --> 00:04:26.959 Kestrel and when you look at the tech empower benchmarks 96 00:04:26.959 --> 00:04:31.480 for this, Kestrel consistently ranks among the top ten fastest 97 00:04:31.600 --> 00:04:33.800 mainstream full stack web frameworks in the world. 98 00:04:33.879 --> 00:04:37.399 It's incredibly fast, and the performance leap comes mostly from. 99 00:04:37.240 --> 00:04:38.480 What Kestrel doesn't do. 100 00:04:38.680 --> 00:04:39.959 Okay, what do you mean, Well. 101 00:04:39.879 --> 00:04:44.560 The legacy ICE integration forced every single HTTP request through 102 00:04:44.639 --> 00:04:48.120 this bloated pipeline of modules, right like it would check 103 00:04:48.160 --> 00:04:52.480 for legacy Windows authentication protocols or active directory hooks, things 104 00:04:52.480 --> 00:04:54.399 that modern rest APIs. 105 00:04:53.959 --> 00:04:54.920 Simply don't use. 106 00:04:55.240 --> 00:04:56.360 Just a bunch of dead weight. 107 00:04:56.480 --> 00:04:58.800 Exactly, So Kestrel strips all of that away. 108 00:04:58.800 --> 00:05:02.240 It's built on modern asynchronous IO and non blocking. 109 00:05:01.879 --> 00:05:04.000 Sockets, not just sitting around waiting, right. 110 00:05:04.079 --> 00:05:06.680 It doesn't waste thread capacity waiting for a disc or 111 00:05:06.720 --> 00:05:10.240 network operation to finish. It acts as this incredibly lean, 112 00:05:10.879 --> 00:05:15.920 specialized processing engine optimized purely for raw HTTP throughput. 113 00:05:16.079 --> 00:05:20.079 Okay, let's unpack this because knowing Kestrel is that fast 114 00:05:20.360 --> 00:05:24.600 makes the actual deployment architecture seem well a little contradictory. 115 00:05:24.639 --> 00:05:26.800 How so, so our source material points out that an 116 00:05:26.839 --> 00:05:30.160 average web page day the Amazon hometage, for example, it 117 00:05:30.199 --> 00:05:34.319 fires off nearly three hundred separate HTTP requests just to 118 00:05:34.360 --> 00:05:35.319 render a single view. 119 00:05:35.439 --> 00:05:37.240 Oh yeah, mostly images and scripts. 120 00:05:37.360 --> 00:05:40.480 Right, So that obviously needs to be handled with extreme efficiency. 121 00:05:41.079 --> 00:05:43.959 But when one of those requests hits an ASP dot 122 00:05:44.000 --> 00:05:47.360 net core server, it doesn't actually go straight to Kestrel. 123 00:05:47.560 --> 00:05:48.120 No, it doesn't. 124 00:05:48.160 --> 00:05:51.920 It's a reverse proxy first, like Nginx or apacheon Linux 125 00:05:52.000 --> 00:05:55.360 or isis on Windows. So why build a blazing fast 126 00:05:55.399 --> 00:05:59.399 server like Kestrel only to bottleneck the whole architecture by 127 00:05:59.439 --> 00:06:02.720 placing a second, older web server directly in front of it. 128 00:06:02.720 --> 00:06:04.800 It's a great question, and it comes down to a 129 00:06:04.839 --> 00:06:08.759 really strict architectural boundary. It's about the separation of concerns. Okay, 130 00:06:08.959 --> 00:06:11.279 the public Internet is frankly. 131 00:06:11.040 --> 00:06:12.959 Chaotic, absolute wild west. 132 00:06:13.079 --> 00:06:16.360 Yeah, server is constantly getting bombarded with slow Loris attacks, 133 00:06:16.439 --> 00:06:20.560 malformed headers, dedoss attempts, just endless idle connections. 134 00:06:20.040 --> 00:06:22.240 Right, all this garbage traffic exactly. 135 00:06:22.319 --> 00:06:25.319 So Kestrel is an Olympic sprinter. You do not want 136 00:06:25.319 --> 00:06:28.240 your sprinter fighting off a mob before the race even starts. 137 00:06:28.240 --> 00:06:31.480 Oh I like that analogy, right, So a reverse proxy 138 00:06:32.040 --> 00:06:34.839 like Nginx acts as the riot shield. 139 00:06:35.040 --> 00:06:35.759 Riot shield. 140 00:06:35.879 --> 00:06:39.199 Yeah, it's battle hardened over decades to absorb the chaos 141 00:06:39.199 --> 00:06:42.959 of the public Internet. It handles TLS termination, decrypting the 142 00:06:43.079 --> 00:06:46.560 HTTPS traffic, and it manages connection pooling. 143 00:06:46.360 --> 00:06:49.839 So the proxy sanitizes the environment exactly. Kestrel never has 144 00:06:49.839 --> 00:06:53.839 to worry about security protocols or dropped connection yeah. Ngix 145 00:06:54.279 --> 00:06:57.360 just filters out the noise, takes the clean raw bites 146 00:06:57.399 --> 00:07:00.879 of the actual HTTP request, and hands off to Kestral 147 00:07:01.079 --> 00:07:02.959 over a super secure local looppac. 148 00:07:03.319 --> 00:07:06.399 And Kestrel's only concern at that point is parsing those 149 00:07:06.439 --> 00:07:09.439 clean bites. It packages them into a neatly organized C 150 00:07:09.600 --> 00:07:12.120 sharp object called an HTTP. 151 00:07:11.680 --> 00:07:13.759 Context HTTP context Yeah, and. 152 00:07:13.720 --> 00:07:15.600 Then it passes that context down the line for the 153 00:07:15.639 --> 00:07:16.759 application to evaluate. 154 00:07:16.959 --> 00:07:20.000 And because we've severed the application from the operating system, 155 00:07:20.199 --> 00:07:23.399 the application is entirely responsible for figuring out what to 156 00:07:23.439 --> 00:07:25.040 do with that HTTP context, right. 157 00:07:25.079 --> 00:07:27.120 It can't rely on ICE to boot it up anymore 158 00:07:27.240 --> 00:07:29.519 or to tell it how to route the traffic, which. 159 00:07:29.399 --> 00:07:32.160 Leads us perfectly into the anatomy of how an as 160 00:07:32.360 --> 00:07:36.000 dot net core application actually constructs itself. Because when a 161 00:07:36.040 --> 00:07:39.199 developer opens a new project, they are immediately confronted with 162 00:07:39.319 --> 00:07:44.079 two foundational files, program dot cs and startup dot cs. 163 00:07:44.240 --> 00:07:47.120 Yeah, and for developers coming from legacy web backgrounds. Program 164 00:07:47.160 --> 00:07:50.240 dot cs appears deeply counterintuitive, oh for sure, because it 165 00:07:50.240 --> 00:07:51.879 contains a static void main. 166 00:07:51.720 --> 00:07:55.040 Function, which is I mean, that's the exact signature you 167 00:07:55.160 --> 00:07:58.160 use for a standard run of the mill console application 168 00:07:58.279 --> 00:08:00.360 in like a beginner's programming class. 169 00:08:00.439 --> 00:08:00.759 Exactly. 170 00:08:00.839 --> 00:08:04.279 An enterprise grade cloud scalable web app is, under the hood, 171 00:08:04.560 --> 00:08:07.240 just a console application that spins up a web post 172 00:08:07.279 --> 00:08:08.319 and refuses to acceit. 173 00:08:08.480 --> 00:08:11.519 That is so wild. So program dot cs handles all 174 00:08:11.560 --> 00:08:15.360 the heavy structural plumbing yep. It configures kestrol, it wires 175 00:08:15.439 --> 00:08:18.439 up the logging providers, It establishes the connection to that 176 00:08:18.680 --> 00:08:22.560 Nginx reverse proxy we just talked about. Basically, it builds 177 00:08:22.560 --> 00:08:23.519 the physical. 178 00:08:23.079 --> 00:08:26.079 Building, right, but the building is completely empty until the 179 00:08:26.160 --> 00:08:28.319 framework evaluates startup dot cs. 180 00:08:28.480 --> 00:08:29.600 The personalities exactly. 181 00:08:29.600 --> 00:08:32.879 Startup dot CS injects the logic, the routing rules, the 182 00:08:32.879 --> 00:08:34.480 whole personality of the application. 183 00:08:34.919 --> 00:08:37.159 So it's the menu and the staff of the restaurant. 184 00:08:37.320 --> 00:08:39.399 That's a perfect way to put it. And the really 185 00:08:39.480 --> 00:08:44.120 fascinating mechanical detail here is how the framework actually interacts 186 00:08:44.200 --> 00:08:44.799 with this file. 187 00:08:45.279 --> 00:08:47.320 Right. Because it's not a standard interface, is it. 188 00:08:47.720 --> 00:08:53.399 No, startup doesn't implement a rigid, predefined interface. Instead, the 189 00:08:53.440 --> 00:08:55.120 framework utilizes reflection. 190 00:08:55.279 --> 00:08:55.679 Reflection. 191 00:08:55.840 --> 00:08:58.879 Yeah, so during the boot process, the dot Net run 192 00:08:58.960 --> 00:09:03.080 time scans its own compiled assembly memory. It actively searches 193 00:09:03.080 --> 00:09:06.360 for a class named startup, and then it stands inside 194 00:09:06.399 --> 00:09:10.240 that class for two specific method signatures. 195 00:09:09.679 --> 00:09:13.159 Configure services and configure You got it, And reflection allows 196 00:09:13.159 --> 00:09:18.039 the framework to dynamically invoke those methods at runtime without 197 00:09:18.080 --> 00:09:20.840 making the developer inherit from some bloated base class. 198 00:09:21.000 --> 00:09:22.720 Exactly. It keeps things so clean. 199 00:09:23.080 --> 00:09:26.679 So let's look at that first dynamically invoked method, configure services. 200 00:09:26.879 --> 00:09:31.360 This is the mechanism the application uses to handle dependency injection. Ah. Yes, 201 00:09:31.480 --> 00:09:34.080 dependency injection, which is a concept that often gets treated 202 00:09:34.159 --> 00:09:36.720 like you know, dark magic. But it's actually a very 203 00:09:36.840 --> 00:09:40.080 rigid system built around the single responsibility principle. 204 00:09:40.279 --> 00:09:42.320 Yeah, it's very logical once you break it down. 205 00:09:42.399 --> 00:09:43.960 So how does the source break it down? 206 00:09:44.159 --> 00:09:47.639 Well, say an application needs to calculate an order total. 207 00:09:48.279 --> 00:09:50.759 That logic shouldn't be cluttered up with all the math 208 00:09:50.840 --> 00:09:54.080 required to determine state tax or figure out shipping weight. 209 00:09:54.240 --> 00:09:55.759 Right, you want to keep that separate. 210 00:09:55.480 --> 00:09:58.679 So you create a distinct tax calculator class. And a 211 00:09:58.759 --> 00:10:00.279 separate shipping service. 212 00:10:00.080 --> 00:10:01.120 Class makes sense. 213 00:10:01.639 --> 00:10:05.720 Now, in a tightly coupled legacy application, your order service 214 00:10:06.000 --> 00:10:10.559 would manually instantiate those dependencies using the new keyword. 215 00:10:10.679 --> 00:10:12.279 Oh so you'd say new tax. 216 00:10:12.039 --> 00:10:15.559 Calculator exactly, which means your order service becomes hard coded 217 00:10:15.600 --> 00:10:17.279 to those specific implementations. 218 00:10:17.320 --> 00:10:20.399 And if the tax calculator certainly needs to say poll 219 00:10:20.600 --> 00:10:25.039 data from a third party API, and now it requires 220 00:10:25.080 --> 00:10:28.720 an apikey in its constructor, you have to go back 221 00:10:28.720 --> 00:10:31.080 and rewrite the order service just to pass that new 222 00:10:31.120 --> 00:10:32.200 parameter down right. 223 00:10:32.240 --> 00:10:36.080 It causes this cascating failure across your entire code base. 224 00:10:36.159 --> 00:10:37.279 It's an absolute headache. 225 00:10:37.320 --> 00:10:40.200 But dependency injection solves this by using an inversion of 226 00:10:40.240 --> 00:10:45.240 control container, which is basically a centralized registry of recipes recipe. Yeah, 227 00:10:45.320 --> 00:10:49.600 so inside configure services, the developer registers those recipes. They 228 00:10:49.600 --> 00:10:52.799 tell the IOC container, Hey, whenever a class asks for 229 00:10:52.840 --> 00:10:57.360 the i tax calculator interface, instantiate this specific tax calculator class. 230 00:10:57.440 --> 00:11:00.120 Got it. So when the order service boots up, it 231 00:11:00.200 --> 00:11:03.720 simply declares its requirements in its constructor yep, and then 232 00:11:03.840 --> 00:11:09.080 the framework just pauses consults its internal registry recursively builds 233 00:11:09.080 --> 00:11:13.399 the entire tree of required dependencies and injects them seamlessly exactly. 234 00:11:13.759 --> 00:11:16.279 The service never cares how the text calculator was built 235 00:11:16.559 --> 00:11:19.200 or what its underlying dependencies are. It just trusts the 236 00:11:19.240 --> 00:11:20.440 container to provide it. 237 00:11:20.639 --> 00:11:23.320 That is so elegant. So once the services are mapped 238 00:11:23.320 --> 00:11:26.279 out in configure services, the framework moves on to the 239 00:11:26.360 --> 00:11:28.440 second method it found vieaw reflection. 240 00:11:28.480 --> 00:11:30.519 The configure method, right, and this. 241 00:11:30.480 --> 00:11:34.519 Method explicitly defines the middleware pipeline. It dictates exactly how 242 00:11:34.600 --> 00:11:37.879 that httke pot context object, the one generated by kestrel, 243 00:11:38.039 --> 00:11:39.120 is going to be processed. 244 00:11:39.240 --> 00:11:43.480 Fundamentally, the pipeline is an assembly line. The HTTP context 245 00:11:43.519 --> 00:11:47.039 travels through a sequence of middleware components. These are small, 246 00:11:47.360 --> 00:11:50.559 really focused blocks of code that can inspect the request, 247 00:11:51.039 --> 00:11:55.799 modify it, or generator response. The application defines this sequence 248 00:11:55.879 --> 00:11:59.480 in configure, and this is crucial. The order of execution 249 00:12:00.120 --> 00:12:01.120 is absolute. 250 00:12:01.200 --> 00:12:03.080 It is absolute, and that can be a trap. Right, 251 00:12:03.159 --> 00:12:07.000 Like what happens if a developer carelessly places authorization middleware 252 00:12:07.440 --> 00:12:08.960 before authentication middleware. 253 00:12:09.039 --> 00:12:12.080 Oh that triggers a catastrophic logic failure. 254 00:12:12.200 --> 00:12:12.519 Yeah. 255 00:12:12.600 --> 00:12:15.559 Yeah, because the pipeline attempts to verify if the user 256 00:12:15.639 --> 00:12:19.360 has admin privileges before the system has even extracted the 257 00:12:19.440 --> 00:12:22.360 user's identity claims from their authentication cookie. 258 00:12:22.039 --> 00:12:23.759 Because they haven't authenticated. 259 00:12:23.279 --> 00:12:25.759 Yet exactly, So the pipeline triggers a four oh one 260 00:12:25.840 --> 00:12:30.039 unauthorized instantly. It locks out valid users simply because the 261 00:12:30.159 --> 00:12:32.399 HTTP context assembly line. 262 00:12:32.200 --> 00:12:33.000 Was out of order. 263 00:12:33.279 --> 00:12:35.159 Wow, so order is everything. 264 00:12:34.879 --> 00:12:39.080 Absolutely, But beyond strict ordering, the pipeline's behavior can also 265 00:12:39.200 --> 00:12:41.879 dynamically mutate based on its deployment environment. 266 00:12:41.960 --> 00:12:44.639 Right, and that's managed by an injected parameter called IE 267 00:12:44.639 --> 00:12:45.559 hosting environment. 268 00:12:45.919 --> 00:12:49.639 Yes, the framework checks a simple environment variable on the 269 00:12:49.679 --> 00:12:52.039 host machine to determine if it's running locally on a 270 00:12:52.080 --> 00:12:55.080 developer's laptop or if it's you know, live in a 271 00:12:55.120 --> 00:12:56.320 production server cluster. 272 00:12:56.480 --> 00:13:00.000 Which is so smart because if the environment variable reads development, 273 00:13:00.919 --> 00:13:04.960 the framework wires up the developer exception page middleware. 274 00:13:04.720 --> 00:13:06.480 Ah, the white screen of death. 275 00:13:06.559 --> 00:13:09.240 The white screen of death, but a helpful one. When 276 00:13:09.279 --> 00:13:14.120 the code inevitably crashes, this middleware catches the exception and 277 00:13:14.159 --> 00:13:16.600 renders this deeply diagnostic web page. 278 00:13:16.720 --> 00:13:17.440 It's incredible. 279 00:13:17.480 --> 00:13:22.320 It exposes raw stack traces, memory variables, database connection strings. 280 00:13:22.039 --> 00:13:24.879 Even the exact line of failing c Sharre code directly 281 00:13:24.919 --> 00:13:25.519 in the browser. 282 00:13:25.679 --> 00:13:27.799 Yeah, it is an amazing tool for tracking down a 283 00:13:27.879 --> 00:13:29.159 null reference bug. 284 00:13:29.120 --> 00:13:32.279 But exposing all those deep structural details. It's also a 285 00:13:32.320 --> 00:13:35.480 massive security vulnerability if that ever got deployed to the 286 00:13:35.519 --> 00:13:36.200 public Internet. 287 00:13:36.279 --> 00:13:38.000 Oh, a catastrophic vulnerability. 288 00:13:38.120 --> 00:13:41.960 Right. So, by reading the environment variable, the framework structurally 289 00:13:42.000 --> 00:13:43.519 protects the application. 290 00:13:43.200 --> 00:13:47.000 Exactly in a production environment, it bypasses that developer exception 291 00:13:47.039 --> 00:13:51.159 page entirely, and it wires up an exception handler middleware instead. 292 00:13:51.360 --> 00:13:52.120 And what does that do. 293 00:13:52.399 --> 00:13:55.960 It catches the crash, swallows the sensitive stack trace, logs 294 00:13:55.960 --> 00:13:59.080 it securely to an internal file, and then returns are 295 00:13:59.120 --> 00:14:03.840 really benign, stylized five hundred internal server error page. 296 00:14:03.559 --> 00:14:04.159 To the user. 297 00:14:04.480 --> 00:14:06.120 Nothing to see here, basically. 298 00:14:05.720 --> 00:14:07.679 Exactly just a polite error message. 299 00:14:07.879 --> 00:14:10.399 Now, since we've removed the rigid structure of ICE, the 300 00:14:10.440 --> 00:14:13.519 application is completely responsible for its own file security too. 301 00:14:13.519 --> 00:14:16.840 Right, It can't hide behind Windows directory permissions anymore. 302 00:14:16.960 --> 00:14:20.759 So that forces a new architectural paradigm for handling static assets, 303 00:14:20.919 --> 00:14:24.120 which introduces a dedicated directory called ww root. 304 00:14:24.320 --> 00:14:29.080 Yeah, the ww root folder it establishes a non negotiable boundary, 305 00:14:29.399 --> 00:14:32.360 a safe zone, a completely safe zone. It acts as 306 00:14:32.360 --> 00:14:36.360 the singular public facing directory for the entire application. Okay, 307 00:14:36.480 --> 00:14:39.480 so the castral server is configured to serve static files 308 00:14:39.519 --> 00:14:44.720 like CSS style sheets, compiled JavaScript bundles images exclusively from 309 00:14:44.720 --> 00:14:45.279 this folder. 310 00:14:45.480 --> 00:14:49.039 So if a malicious actor attempts, say a path traversal 311 00:14:49.080 --> 00:14:52.919 attack like manipulating the URL to request the raw sea 312 00:14:52.960 --> 00:14:56.559 Sharp back end files located just one directory up from ww. 313 00:14:56.279 --> 00:14:59.679 Root, the static file middleware simply ignores the request and 314 00:14:59.679 --> 00:15:01.679 return 's a four h four not found. 315 00:15:02.120 --> 00:15:02.399 Wow. 316 00:15:02.480 --> 00:15:05.320 Yeah, the internal source code is architecturally walled off from 317 00:15:05.320 --> 00:15:06.440 the public routing table. 318 00:15:06.519 --> 00:15:09.600 That is so clean. And this systemic cleanup of the 319 00:15:09.639 --> 00:15:13.000 application structure extends directly into how the project files are 320 00:15:13.000 --> 00:15:13.519 managed too. 321 00:15:13.639 --> 00:15:17.159 Oh thank goodness, because legacy dot net developers spent years 322 00:15:17.200 --> 00:15:18.759 fighting with c sproge files. 323 00:15:18.840 --> 00:15:20.720 Ooh, the c sproge files. 324 00:15:20.480 --> 00:15:26.159 Yah is massive monolithic XML documents filled with seemingly random goods, 325 00:15:26.679 --> 00:15:29.039 and every single file in the application had to be 326 00:15:29.120 --> 00:15:31.559 manually declared in that XML document. 327 00:15:31.720 --> 00:15:34.039 Right, So if two developers on a team added different 328 00:15:34.039 --> 00:15:37.679 files to the project on separate branches, merging, that resulting 329 00:15:37.759 --> 00:15:39.639 c's prod conflict was. 330 00:15:39.639 --> 00:15:41.799 Agonizing hours of lost productivity. 331 00:15:41.919 --> 00:15:44.879 But aspn at core modernized the build engine to use 332 00:15:44.919 --> 00:15:48.679 implicit file includes. Yes, the compiler simply scans the project 333 00:15:48.679 --> 00:15:52.000 directory and automatically assumes any c sharp file it finds 334 00:15:52.240 --> 00:15:54.519 is part of the application. So the XML file is 335 00:15:54.519 --> 00:15:56.720 stripped down to just a few readable lines, and. 336 00:15:56.679 --> 00:15:59.440 The dependency management got the same aggressive optimization. 337 00:15:59.679 --> 00:15:59.919 Right. 338 00:16:00.080 --> 00:16:04.120 Instead of a massive list of individual package references, developers 339 00:16:04.159 --> 00:16:07.559 now use a meta package like Microsoft dot asp Net Core. 340 00:16:08.000 --> 00:16:10.240 Oh so it's like an umbrella exactly. 341 00:16:10.480 --> 00:16:12.919 It acts as an umbrella reference, pulling in the entire 342 00:16:12.960 --> 00:16:16.360 supported ecosystem of asp dot net Core libraries behind the 343 00:16:16.360 --> 00:16:18.679 scenes without cluttering up the project file. 344 00:16:18.759 --> 00:16:21.960 Now here's where it gets really interesting. Abstracting away that 345 00:16:22.039 --> 00:16:25.080 complexity enables the most significant workflow shift of all. 346 00:16:25.200 --> 00:16:26.200 Yeah, it really does. 347 00:16:26.320 --> 00:16:28.879 Because the build engine and the project files are so lean. Now, 348 00:16:29.279 --> 00:16:33.000 developers are no longer shackled to a massive, gigabyte heavy 349 00:16:33.279 --> 00:16:36.039 integrated development environment like visual Studio. 350 00:16:36.200 --> 00:16:40.159 Right, the underlying compiler mechanics are exposed directly through the 351 00:16:40.200 --> 00:16:43.320 dot Net command line interface, the CLI. The CLI it 352 00:16:43.360 --> 00:16:47.440 completely democratizes the framework. A developer opens a basic terminal 353 00:16:47.440 --> 00:16:50.360 on a Linux machine and runs dot net new MBC 354 00:16:50.519 --> 00:16:52.120 to generate the templated. 355 00:16:51.720 --> 00:16:53.360 Architecture just one command yep. 356 00:16:53.720 --> 00:16:56.639 Then running dot net restore resolves the package dependencies over 357 00:16:56.679 --> 00:16:59.600 the network. Dot Net build invokes the MS build engine 358 00:16:59.639 --> 00:17:00.919 to comp file the source. 359 00:17:00.679 --> 00:17:03.960 Code, and then dot net run spins up the Kestrel server, 360 00:17:04.400 --> 00:17:07.119 binding it to a local port for testing. So a 361 00:17:07.160 --> 00:17:10.640 workflow that previously required a dedicated Windows machine and expensive 362 00:17:10.640 --> 00:17:14.759 IDE license and hours of configuration can now be executed 363 00:17:14.960 --> 00:17:18.319 entirely from a lightweight text editor like visual Studio code 364 00:17:18.359 --> 00:17:19.039 on a MacBook. 365 00:17:19.079 --> 00:17:19.799 It's beautiful. 366 00:17:19.839 --> 00:17:22.599 It removes every barrier to entry that kept the Microsoft 367 00:17:22.640 --> 00:17:26.599 stack isolated from the broader open source community for a decade. 368 00:17:26.200 --> 00:17:26.680 And a half. 369 00:17:26.759 --> 00:17:27.680 So what does this all mean? 370 00:17:28.039 --> 00:17:30.440 Well, stepping back to look at the entire scope of 371 00:17:30.440 --> 00:17:33.359 what we've unpacked, it becomes pretty clear that asp net 372 00:17:33.359 --> 00:17:36.279 core is not merely an iterative update, not at all. 373 00:17:36.400 --> 00:17:40.599 It is a fundamental reinvention of Microsoft's web philosophy. It 374 00:17:40.720 --> 00:17:47.160 prioritizes decoupled modularity, relentless speed via Kestrel, and absolute platform independence. 375 00:17:47.559 --> 00:17:51.000 You the listener, now have a comprehensive mental map of 376 00:17:51.039 --> 00:17:55.240 how a modern web request travels. You know why Nginx 377 00:17:55.359 --> 00:17:58.839 acts as the riot shield, absorbing the chaos before handing 378 00:17:58.839 --> 00:18:02.240 the raw bites to Kestrel. You understand how Kestrel packages 379 00:18:02.279 --> 00:18:05.920 that data and sends it down a rigidly defined middleware 380 00:18:06.000 --> 00:18:09.519 pipeline dictated by startup dot cos. You see how the 381 00:18:09.559 --> 00:18:14.440 IOC container uses reflection and dependency injection to map interfaces 382 00:18:14.519 --> 00:18:15.799 to implementations on the fly. 383 00:18:16.039 --> 00:18:18.119 You aren't just memorizing syntax. 384 00:18:17.680 --> 00:18:22.359 Anymore, right, You are deeply understanding the architectural machinery driving 385 00:18:22.440 --> 00:18:23.680 the modern web. 386 00:18:23.720 --> 00:18:27.960 And analyzing that machinery presents a really fascinating concept to 387 00:18:28.000 --> 00:18:29.079 consider going forward. 388 00:18:29.200 --> 00:18:29.519 What's that? 389 00:18:29.799 --> 00:18:33.000 Well, we've seen how asp dot net core turns everything 390 00:18:33.079 --> 00:18:37.160 into an interchangeable dependency. The application is completely decoupled from 391 00:18:37.200 --> 00:18:40.119 the operating system, and the Kestral server itself is just 392 00:18:40.160 --> 00:18:43.240 another modular component spun up by a console app. 393 00:18:43.400 --> 00:18:43.720 Yeah. 394 00:18:43.880 --> 00:18:46.720 So if back end architecture is becoming this lightweight, this 395 00:18:46.960 --> 00:18:52.079 universally portable, and this fundamentally disconnected from the underlying host. 396 00:18:51.759 --> 00:18:53.400 Hardware, where are you going with this? 397 00:18:53.839 --> 00:18:56.680 What is stopping the traditional boundary between the server and 398 00:18:56.720 --> 00:19:01.200 the browser from eventually blurring into one unified, location agnostic 399 00:19:01.319 --> 00:19:02.480 execution environment. 400 00:19:02.799 --> 00:19:06.920 Oh wow, that implies a future where the execution environment 401 00:19:07.160 --> 00:19:11.839