Einführung in ASP.NET Core Middlewares

Matthias Jauernig
www.jauernig-it.de
matthias@jauernig-it.de
@JauernigIT
Frankfurt/Rhein-Main
Professionell. Individuell. Innovativ.
ASP.NET Core Middlewares

Matthias Jauernig
Sourcecode zum Vortrag
 https://github.com/JauernigIT/aspnetcore_middlewares
 Demo für Run/Use/Map
 Demo für Angular 4 mit ASP.NET Core inkl. 2 Middlewares (SPA Routing, Old Browser Detection)
 Demo für Response-Veränderung (Filtern von Schimpfwörtern)
26.06.2017 Matthias Jauernig - ASP.NET Core Middlewares 2

Matthias Jauernig
Wer ich bin
 Freiberuflicher Webentwickler/-architekt
 Raum Frankfurt / Rhein-Main
 10 Jahre Erfahrung in professioneller Softwareentwicklung
 C#/.NET, .NET Core, ASP.NET MVC, TypeScript, Angular 4, Kendo UI
Wie ich zu .NET Core komme
 Privat & aktuelles Projekt (Bank, öffentliche Webseite)
 Frontend: Single Page Application (SPA)
Backend: .NET Core als leichtgewichtige Hosting-Lösung
 20 genutzte Middlewares, davon 12 eigenentwickelt
www.jauernig-it.de

Was ist eine Middleware?
Argonne National Laboratory
CC BY-SA 2.0, @Wikimedia
?

Das ist eine Middleware:
app.Run(async context =>
{
await context.Response
.WriteAsync("Hello World!");
});

Definition
“Middleware is software that is
assembled into an application pipeline
to handle requests and responses.”
Quelle: ASP.NET Core Docs, Microsoft

ASP.NET Core Middleware  Request Delegate
public Task Invoke(HttpContext context)
{
// do something
}

Basierend auf Best Practices der WebDev Community
 Node.js Express
 Rails on Rack
 …
Evolution aus OWIN Middlewares
 Konzept der Middleware-Pipeline zur Verarbeitung von Requests/Responses
 Einfacher als OWIN Middlewares (zusätzliche Abstraktionen), verbessertes DI
 Nutzbarkeit von OWIN Middlewares in ASP.NET Core (app.UseOwin())

Ablösung von HTTP-Handlern und HTTP-Modulen
Authorization
Module Andere Module
MVC
HTTP Handler
.report
HTTP Handler
Unauthorized
request
Request for
/Home/Index
Request for
/sales.report

Middlewares vs. HTTP-Handler/Module
HTTP-Handler/Module
 Handler: Request-Verarbeitung abhängig von Dateiname/Dateiendung
 Module:
 für jeden Request ausgeführt
 Reihenfolge abhängig von Lifecycle Events und web.config
 Ablösung/Vereinheitlichung beider Konzepte
 Einfacher und verständlicher als HTTP-Handler/Module (keine magic classes)
 Pipeline-Definition und Reihenfolge per Code (keine magic web.config)
 Flexibilität in Pipeline-Aufbau (Verzweigungen, etc.)

Die Request-Pipeline aufbauen
Request-Verarbeitung: Run()
 Request verarbeiten und direkt zurückkehren
Run()

Request-Verarbeitung: Use()
 Request verarbeiten und nächste Middleware in der Pipeline aufrufen
Use() Run()Use()

Request-Verarbeitung: Map()
 auf eine andere Pipeline verzweigen, abhängig von einer festgelegten Bedingung
Run()Map()Use()
Use()
Use()

Ausführungsreihenfolge

Reihenfolge ist entscheidend!
 Verhalten: wird das Gewünschte getan?
 Sicherheit: wird zu viel Information preisgegeben?
 Performance: wird zu viel ausgeführt?
Verbesserung der Performance
 Häufig ausgeführte Operationen weiter oben
 Ressourcenintensive Operationen weiter unten
 Nur möglich, wenn Verhalten nicht beeinträchtigt wird

Eingebaute Middlewares nutzen
 Authentication
 CORS
 Error Handling
 Response Caching
 Response Compression
 Routing
 Session
 File Server
 Static Files
 URL Rewriting
 MVC
 …

Eigene Middlewares schreiben
Eigene Middleware-Klassen
class SomethingMiddleware {
private RequestDelegate next;
public SomethingMiddleware(RequestDelegate next) {
this.next = next;
}
public async Task Invoke(HttpContext context) {
// do something ...
await next(context);
}
}

Best Practice: IApplicationBuilder Erweiterungsmethode
static class IApplicationBuilderExtensions {
public static IApplicationBuilder
UseSomething(this IApplicationBuilder app) {
return app.UseMiddleware<SomethingMiddleware>();
}}
 „Factory-Methode“ zur Erzeugung der Middleware
 Übergabe von Konstruktor-Parametern manuell möglich (DI automatisch)

Demo Veralteten Browser erkennen

Response verändern - Achtung!
 Response (Header, Body) kann nur vor dem ersten Schreiben verändert werden
 Response wird aus Performancegründen gestreamt
 Beim ersten Schreiben des Response Bodies beginnt der Server die Header zu senden
 Header, Status Code etc. können nur vor dem ersten Schreiben geändert werden
 Generelle Regel: beim Schreiben des Response die Pipeline beenden
 Response nicht mehr nach dem Aufruf der nächsten Middleware ändern

Response verändern - Was tun?
 Beispiel: alle „Schimpfwörter“ sollen aus dem Response-Content entfernt werden
 Möglichkeit 1: nicht durch Middleware lösen, sondern tiefer in der Businesslogik
 Möglichkeit 2: temporärer MemoryStream (Achtung  Performance!)
 Beispiel: Header-Feld ändern (Cache, StatusCode, Encoding, …)
 context.Response.OnStarting() abonnieren

Anwendungsfälle
Einsatz im aktuellen Projekt
 Angular/SPA Routing
 Mobile Device Detection
 Prerendering der SPA (prerender.io)
 Proxy (z.B. zu Web API)
 Dynamische sitemap.xml und robots.txt-Builder
 Detektion alter Browser
 Caching mit speziellen Caching-Regeln
 Filterung von Requests
 Autorisierung/Authentifizierung
 …

Zusammenfassung
Warum Middlewares nutzen?
 Zentrales Konzept von ASP.NET Core
 Cross-Platform
 Einfach zu implementieren
 Pipeline-Aufbau: Volle Flexibilität und Transparenz
 Performance! https://www.techempower.com/blog/2016/11/16/framework-benchmarks-round-13/
 um ein Vielfaches schneller als ASP.NET oder Mono

Einführung in ASP.NET Core Middlewares

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Einführung in ASP.NET Core Middlewares

Similar to Einführung in ASP.NET Core Middlewares (20)

Einführung in ASP.NET Core Middlewares