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

Weitere ähnliche Inhalte

Was ist angesagt?

Einführung in ASP.NET Core Middlewares