Deno on 0xMax42 - Flatfile-Purist. Autodidakt. Systemdenker.

HTTP Kernel v0.2.0 – Von dynamischem Dispatch zur vorkompilierten Pipeline

Tue, 27 May 2025 13:00:00 +0000

Mit v0.2.0 hat mein Deno‑basierter HTTP Kernel einen entscheidenden Schritt gemacht: Statt jede Middleware bei jedem Request dynamisch zu verkettet, wird die gesamte Kette jetzt einmalig kompiliert. Das reduziert Overhead, vereinfacht die Fehlerbehandlung – und macht das Routing spürbar schneller.

Ausgangslage

Die erste Generation des Kernels setzte auf einen rekursiven dispatch()‑Mechanismus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


private async executePipeline(
 ctx: TContext,
 middleware: Middleware<TContext>[],
 handler: Handler<TContext>,
): Promise<Response> {
 const handleInternalError = (ctx: TContext, err?: unknown) =>
 this.cfg.httpErrorHandlers[HTTP_500_INTERNAL_SERVER_ERROR](
 ctx,
 normalizeError(err),
 );

 let lastIndex = -1;

 const dispatch = async (currentIndex: number): Promise<Response> => {
 if (currentIndex <= lastIndex) {
 throw new Error('Middleware called `next()` multiple times');
 }
 lastIndex = currentIndex;

 const isWithinMiddleware = currentIndex < middleware.length;
 const fn = isWithinMiddleware ? middleware[currentIndex] : handler;

 if (isWithinMiddleware) {
 if (!isMiddleware(fn)) {
 throw new Error('Expected middleware function, but received invalid value');
 }
 return await fn(ctx, () => dispatch(currentIndex + 1));
 }

 if (!isHandler(fn)) {
 throw new Error('Expected request handler, but received invalid value');
 }

 return await fn(ctx);
 };

 try {
 const response = await dispatch(0);
 return this.cfg.decorateResponse(response, ctx);
 } catch (e) {
 return handleInternalError(ctx, e);
 }
}

Dieser Ansatz war leicht zu verstehen, erzeugte aber pro Request mehrere Closures, Index‑Prüfungen und Typ‑Checks – alles Dinge, die bei hoher Parallelität unnötig Zeit kosten.

Der neue Ansatz

Beim Registrieren einer Route wird nun eine statisch verlinkte Funktionskette erzeugt. Ergebnis ist eine einzige Funktion runRoute(ctx), die alle Middlewares und den Handler inline ausführt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


private compile(
 route: Omit<IInternalRoute<TContext>, 'runRoute' | 'matcher' | 'method'>,
): (ctx: TContext) => Promise<Response> {
 if (!isHandler<TContext>(route.handler)) {
 throw new TypeError('Route handler must be a function returning a Promise<Response>.');
 }
 let composed = route.handler;

 for (let i = route.middlewares.length - 1; i >= 0; i--) {
 if (!isMiddleware<TContext>(route.middlewares[i])) {
 throw new TypeError(`Middleware at index ${i} is not a valid function.`);
 }

 const current = route.middlewares[i];
 const next = composed;

 composed = async (ctx: TContext): Promise<Response> => {
 let called = false;
 return await current(ctx, async () => {
 if (called) {
 throw new Error(`next() called multiple times in middleware at index ${i}`);
 }
 called = true;
 return await next(ctx);
 });
 };
 }

 return composed;
}

Wichtig: Jede Middleware bekommt weiterhin ihr next() – jedoch kann dieses dank called‑Flag nur noch einmal aufgerufen werden, was Mehrfach‑Ausführungen zuverlässig verhindert.

Benchmarks

Gemessen mit 10 000 parallelen Requests auf einem Ryzen 7 8845HS:

Benchmark (parallel)	v0.1.0 (dynamisch)	v0.2.0 (vorkompiliert)	Gewinn
Simple Route	5.4 ms	2.1 ms	≈ 61 %
Complex Route	11.2 ms	7.9 ms	≈ 29 %

Bei Einzeln‑Requests liegen die Werte nahezu gleichauf – der Geschwindigkeitsvorteil zeigt sich vor allem unter hoher Last.

Fazit

Statisches Routing reduziert Overhead und steigert Durchsatz signifikant.
next()‑Fehler werden jetzt sofort erkannt.
API blieb kompatibel – Upgrade von 0.1.x auf 0.2.0 ist ohne Code‑Änderungen möglich.

Der Kernel läuft bereits performant und stabil in meinem build‑cache‑server – einem Deno‑basierten Build‑Cache für act; kompatiibel mit der Github Actions Cache API.

👉 Quellcode & Release‑Notes: https://github.com/0xMax42/http-kernel

Systemd-Timer per CLI erstellen – einfach, schnell, nervenschonend

Sat, 24 May 2025 21:30:00 +0000

Wer schon mal versucht hat, systemd-Timer von Hand zu schreiben, weiß: So richtig Spaß macht das nicht. Zwischen .service- und .timer-Dateien, Pfadangaben, und OnCalendar-Syntax kann man sich schnell vertun. Genau dafür habe ich mir ein kleines Tool gebaut: systemd-timer.

Was macht das Ding?

Ganz einfach: Du rufst ein CLI auf, gibst ein paar Parameter an, und das Tool schreibt dir die passenden .service- und .timer-Units – inklusive Logging, Abhängigkeiten und allem, was systemd eben braucht. Keine Vorlage kopieren, keine Tippfehler mehr, kein Nachdenken darüber, ob das jetzt WantedBy=timers.target heißen muss oder nicht.

Warum nicht einfach `cron`?

Klar, cron funktioniert. Aber systemd hat ein paar Vorteile:

Besseres Logging (auch in Datei)
Einfache Integration mit anderen Diensten (z. B. Netzwerkwarten)
Funktioniert auch pro Benutzer (ohne root-Rechte)
Alles bleibt in einer Sprache: systemd

Das CLI hilft dabei, die Einstiegshürde zu senken und trotzdem “richtig” mit systemd zu arbeiten.

Was kann `systemd-timer`?

.service + .timer-Dateien erstellen
--user-Timer (für Desktop- oder Container-Umgebungen)
Logging per --logfile
Standard-Optionen wie:
- --exec, --calendar, --after, --environment
- --description, --output, --dry-run
CLI basiert auf Cliffy, getippt mit Deno
Plattformunabhängige Installation per Shell-Skript

Ein Beispiel, das du sofort nutzen kannst

1
2
3
4
5
6


systemd-timer create \
 --exec "/usr/local/bin/backup.sh" \
 --calendar "Mon..Fri 02:00" \
 --description "Backup Job" \
 --user \
 --logfile "/var/log/backup.log"

Ergebnis:

~/.config/systemd/user/backup.service
~/.config/systemd/user/backup.timer

Aktivieren:

1
2


systemctl --user daemon-reload
systemctl --user enable --now backup.timer

Installation: Ein Einzeiler

1

curl -fsSL https://git.0xmax42.io/maxp/systemd-timer/raw/branch/main/scripts/install.sh | sh

Das Skript erkennt automatisch deine Architektur (amd64/arm64), lädt die passende Binary und prüft sie mit SHA256. Und ja, du kannst dir den Code vorher anschauen, bevor du ihn durch die Leitung jagst.

Entwicklung & Test

Das Tool ist komplett mit TypeScript/Deno geschrieben, ordentlich typisiert und testgetrieben. Alles Wichtige ist modular aufgebaut, damit man es auch als Bibliothek verwenden könnte.

Tests laufen einfach per:

1

deno task test

Fazit

systemd-timer ist kein Monster-Tool mit 1000 Optionen – sondern genau das, was man sich wünscht, wenn man öfter mal einfache Tasks zeitgesteuert per systemd laufen lassen will, ohne sich jedes Mal die Finger wundzuschreiben. Es richtet sich an Leute, die lieber deklarativ als improvisiert arbeiten.

Quellcode, Releases und alles Weitere findest du hier: 👉 git.0xmax42.io/maxp/systemd-timer

Deno on 0xMax42 - Flatfile-Purist. Autodidakt. Systemdenker.

HTTP Kernel v0.2.0 – Von dynamischem Dispatch zur vorkompilierten Pipeline

Ausgangslage

Der neue Ansatz

Benchmarks

Fazit

Systemd-Timer per CLI erstellen – einfach, schnell, nervenschonend

Was macht das Ding?

Warum nicht einfach cron?

Was kann systemd-timer?

Ein Beispiel, das du sofort nutzen kannst

Installation: Ein Einzeiler

Entwicklung & Test

Fazit

Warum nicht einfach `cron`?

Was kann `systemd-timer`?