🧩 Plan: PipelineExecutor<TContext>
🎯 Ziel
Eine eigenständige, testbare Klasse zur Ausführung einer Middleware- und Handler-Pipeline, die:
- Linear und sauber das
next()-Verhalten abbildet - Typvalidierung durchführt (
isMiddleware,isHandler) - Fehler behandelt und an konfigurierbare Handler weiterleitet
- Optionale Hooks zur Tracing-Integration bietet (z. B. für Zeitmessung, Logging)
- Am Ende eine dekorierte
Responsezurückliefert
🧩 Schnittstelle (API)
class PipelineExecutor<TContext extends IContext> {
constructor(cfg: IHttpKernelConfig<TContext>);
run(
ctx: TContext,
middleware: Middleware<TContext>[],
handler: Handler<TContext>,
hooks?: IPipelineHooks<TContext>, // optional
): Promise<Response>;
}
🪝 Hook-Schnittstelle (IPipelineHooks)
interface IPipelineHooks<TContext> {
onPipelineStart?(ctx: TContext): void;
onStepStart?(name: string | undefined, ctx: TContext): void;
onStepEnd?(name: string | undefined, ctx: TContext, duration: number): void;
onPipelineEnd?(ctx: TContext, totalDuration: number): void;
}
nameistundefined, wenn keine.nameam Handler/Middleware gesetzt ist- Diese Hooks ermöglichen später Logging, Zeitmessung, Statistiken etc.
- Der
TraceManagerwird dieses Interface implementieren
🛠️ Interne Aufgaben / Ablauf
run(...)beginnt mit AufrufonPipelineStart(ctx)- Zeitmessung (
performance.now()) - Dispatcher-Funktion führt jede Middleware mit
next()-Kette aus - Vor jedem Aufruf:
onStepStart(name, ctx) - Nach jedem Aufruf:
onStepEnd(name, ctx, duration) - Nach letztem Handler:
onPipelineEnd(ctx, totalDuration) - Ergebnis wird durch
cfg.decorateResponse(res, ctx)geschickt - Im Fehlerfall:
cfg.httpErrorHandlers[500](ctx, error)
✅ Vorteile
HttpKernelist von Ausführungsdetails entkoppelt- Tracing-/Logging-System kann ohne Invasivität angeschlossen werden
- Sehr gut testbar (z. B. Middleware-Mock + Hook-Aufrufe prüfen)
- Erweiterbar für Timeout, Async-Context, Abbruchlogik etc.
📦 Dateiname-Vorschlag
src/Core/PipelineExecutor.tsodersrc/HttpKernel/PipelineExecutor.ts