Here is a concise, interview-ready definition of middleware:
Middleware
Middleware is a component assembled into an application’s request pipeline that handles incoming HTTP requests and outgoing responses. It acts as a series of nested wrappers—allowing you to inspect, route, modify, or short-circuit requests as they flow through the system.
Key points to mention in an interview:
- The Chain: Middleware components are chained together. Each component can perform logic and then either pass control to the next component (via a delegate like `next()`) or short-circuit the pipeline and return a response immediately.
- Bidirectional Execution: Because of the wrapper pattern, a middleware can execute logic on the way in (before the request hits your endpoint) and on the way out (after the endpoint finishes, while the response is heading back to the client).
- Common Use Cases: Authentication, authorization, logging, performance timing, exception handling, and response compression.
Here is a breakdown of common middleware names, an interview-ready definition of filters, and the key differences and use cases for both.
1. Common Built-In Middleware Names
In ASP.NET Core, you see middleware configured via extension methods in Program.cs. Common examples include:
app.UseAuthentication(): Identifies who the user is (parses tokens/cookies).app.UseAuthorization(): Determines if the authenticated user has permission to access a resource.app.UseStaticFiles(): Serves static assets like HTML, CSS, images, and JavaScript directly from thewwwrootfolder.app.UseRouting(): Matches incoming URLs to endpoint routes (like controllers or minimal API endpoints).app.UseExceptionHandler(): Catches unhandled exceptions globally and redirects to an error page or returns a standardized JSON error response.app.UseCors(): Handles Cross-Origin Resource Sharing policies.
2. Definition of a Filter (Interview-Ready)
A filter is an MVC/API-scoped component that hooks into specific stages of the controller action execution lifecycle. It allows you to run code before or after a specific action runs, giving you fine-grained control over authorization, model state validation, caching, or exception handling at the controller/action level.
Types of filters include: IAuthorizationFilter, IResourceFilter, IActionFilter, IExceptionFilter, and IResultFilter.
3. Middleware vs. Filters: Key Differences
| Feature | Middleware | Filters |
|---|---|---|
| Ecosystem | Global pipeline-level. Agnostic of what handles the request (can handle static files, APIs, Blazor, etc.). | MVC/API framework-specific. They only run when a controller or action endpoint is hit. |
| Awareness | Only sees the raw HttpContext. It knows nothing about controllers, action names, or method arguments. | Deeply aware of MVC context (controllers, action names, parameters, and model states). |
| Scope | Typically applied globally to all requests (unless branched with Map). | Can be applied globally, per-controller, or per-action using attributes (e.g., [Authorize]). |
| Execution Order | Executes before endpoint routing resolves the target controller. | Executes after routing has successfully matched the request to a specific controller action. |
4. Use Cases: When to Use Which?
When to Use Middleware:
- Cross-cutting concerns that apply to every single request, regardless of whether it’s a controller, a static file, or a health check (e.g., Request ID generation, global timing/logging, security headers, CORS).
- Infrastructure concerns like authentication parsing (decoding tokens) or global error handling.
When to Use Filters:
- Action-specific logic that only matters for specific controllers or APIs (e.g., custom model validation checks, action result caching, anti-forgery token validation).
- Authorization rules tailored to specific features (e.g., checking if a user owns a specific resource via
[TypeFilter]or action filters). - Short-circuiting specific actions based on business logic before the controller method executes.