We know web applications need middleware to be able to respond to user requests. We also know middleware is made up of a series of components. Now, let’s dive deeper into the technical implementation of these components.
Each middleware component is a request delegate. Remember when we talked about how actions inside of web applications are actually sending requests? Well these requests are sent via Hypertext Transfer Protocol (HTTP). A request delegate is simply a function that can process our HTTP requests.
The request delegates used in middleware are created from either an anonymous method or a reusable class. The components are organized in an ordered sequence with each delegate performing its processing and then calling the next. The sequence continues until either the response is returned or the pipeline short circuits, where the component immediately returns a response instead of calling the next component. The pipeline, created by this sequence of delegates, is ultimately responsible for how web applications receive a user’s request and return an appropriate response.
It’s worth noting that the response is returned in the reverse order of which the request is sent. For example, if the request goes through component A, then component B, then component C, the response is returned by going through Component C, then B, and finally, A. For a visual representation, take a second look at the diagram in the previous exercise.
This diagram shows a Razor Pages app at the system level. HTTP requests hit the server and are passed through the middleware pipeline before reaching a view page. Once a response is generated (usually a rendered web page), it runs back through the middleware pipeline (in reverse order) through the server and returns the response to the browser.