Spine – ein in Korea entwickeltes Backend-Web-Framework ohne Magie

narubrown · 2026-01-18T23:03:16+09:00

Spine ist ein Go-basiertes Backend-Web-Framework, das den Ausführungsfluss nicht verbirgt, sondern explizit sichtbar macht Eine einzelne Pipeline besitzt die gesamte Ausführungsreihenfolge, während sich Controller nur auf die Business-Logik konzentrieren Methodensignaturen sind zugleich der API-Vertrag; es gibt keine annotations- oder conventionsbasierte Automatisierung Die Reihenfolge einer Anfrage ist im Code klar erkennbar Der Fokus liegt weniger auf anfänglicher Produktivität als auf langfristiger Wartbarkeit und einfacher Nachverfolgbarkeit des Ausführungsflusses Echo wird als HTTP-Transport verwendet, und dank ORM-unabhängigem Design können Bun, GORM usw. frei gewählt werden Überblick über Spine Spine ist ein Framework mit dem Ziel, den Ausführungsfluss von Web-Anfragen explizit sichtbar zu machen. Die Ausführungsreihenfolge, die die meisten Frameworks aus Komfortgründen verbergen, wird hier in der Codestruktur fest verankert. Es ist auf eine Struktur ausgerichtet, die klar beantworten kann: „Wo beginnt eine Anfrage, wer verarbeitet sie, und in welcher Reihenfolge wird sie ausgeführt?“ Designprinzipien Keine-Magie-Politik Die einzige Komponente, die die Ausführungsreihenfolge kennt, ist die Pipeline Verhalten, das „sich von selbst erledigt“, wird auf ein Minimum reduziert Alle Erweiterungen und Ausführungen werden explizit registriert und haben eine vorhersehbare Reihenfolge Signaturbasierter Vertrag Die Methodensignatur ist zugleich der API-Vertrag ArgumentResolver übernimmt die Erzeugung der Eingaben, ReturnValueHandler die Verarbeitung der Ausgaben Annotationsbasiertes Mapping und automatische Inferenz auf Basis von Konventionen sind ausgeschlossen Controller-Unabhängigkeit Controller hängen nicht von HTTP-/Transport-Typen ab Es werden nur semantische Typen wie path.*, query.*, httperr.* verwendet Das Ausführungsmodell bleibt dem Controller verborgen, aber die Herkunft der Eingaben wird über Typen explizit gemacht Hauptfunktionen Routing und Parameter Unterstützung für Path Parameter (reihenfolgebasiertes Binding) Query-Values-Utilities (Int-, String- und Boolean-Parsing) Automatisches Binding von Body-DTOs Antwortverarbeitung Automatische Umwandlung von struct -> JSON über ReturnValueHandler Automatisches Mapping von error -> HTTP-Statuscode Semantische Fehlertypen wie httperr.NotFound, BadRequest usw. Querschnittsthemen Interceptor (PreHandle, PostHandle, AfterCompletion) Integrierter CORS-Interceptor IoC-Container auf Konstruktorbasis Architektur Getrennte Transport-Schicht (derzeit Echo, aber austauschbar konzipiert) ORM-unabhängiges Design (Bun, GORM usw. können frei verwendet werden ⚠️ derzeit ist nur die Kompatibilität mit Bun bestätigt) Stärken in groß angelegten Umgebungen Da es nur eine einzige Instanz gibt, die die Ausführungsreihenfolge kennt, sinken die Kosten für die Nachverfolgung des Request-Flows. Querschnittsthemen wie Logging, Transaktionen und Sicherheit werden ausschließlich in der Pipeline platziert, wodurch Anwendungsort und Zeitpunkt vorhersehbar sind. Dafür wird ein Teil der anfänglichen Produktivität geopfert, um langfristig wachsende Komplexität strukturell aufzufangen. Was Spine nicht ist Kein Ersatz für Spring/NestJS Kein Framework zur Maximierung der Produktivität Kein Framework für annotationsbasierte Automatisierung Kein auf HTTP-Engine oder Router zentriertes Framework Ein Projekt, das Unterstützung braucht Spine ist noch kein fertiggestelltes Framework; viele Teile wurden bewusst in unfertigem Zustand veröffentlicht. Es muss überprüft werden, ob sich die Struktur ausreichend gut erklären lässt und ob das Ausführungsmodell reale Probleme tatsächlich gut sichtbar macht. Mitmachen Dem Projekt auf GitHub mit einem ⭐️ folgen Eigene Eindrücke oder Fragen nach dem Ausprobieren als Issue hinterlassen Kritik, Vorschläge und Fragen zum Design in den Kommentaren teilen Referenzlinks Spine-Projekt: https://github.com/NARUBROWN/spine Spine + Bun ORM User Demo: https://github.com/NARUBROWN/spine-user-demo

(na2ru2.me)

13 Punkte von narubrown 2026-01-18 | 2 Kommentare | Auf WhatsApp teilen

Spine ist ein Go-basiertes Backend-Web-Framework, das den Ausführungsfluss nicht verbirgt, sondern explizit sichtbar macht
Eine einzelne Pipeline besitzt die gesamte Ausführungsreihenfolge, während sich Controller nur auf die Business-Logik konzentrieren
Methodensignaturen sind zugleich der API-Vertrag; es gibt keine annotations- oder conventionsbasierte Automatisierung
Die Reihenfolge einer Anfrage ist im Code klar erkennbar
Der Fokus liegt weniger auf anfänglicher Produktivität als auf langfristiger Wartbarkeit und einfacher Nachverfolgbarkeit des Ausführungsflusses
Echo wird als HTTP-Transport verwendet, und dank ORM-unabhängigem Design können Bun, GORM usw. frei gewählt werden

Überblick über Spine

Spine ist ein Framework mit dem Ziel, den Ausführungsfluss von Web-Anfragen explizit sichtbar zu machen.
Die Ausführungsreihenfolge, die die meisten Frameworks aus Komfortgründen verbergen, wird hier in der Codestruktur fest verankert.
Es ist auf eine Struktur ausgerichtet, die klar beantworten kann: „Wo beginnt eine Anfrage, wer verarbeitet sie, und in welcher Reihenfolge wird sie ausgeführt?“

Designprinzipien

Keine-Magie-Politik

Die einzige Komponente, die die Ausführungsreihenfolge kennt, ist die Pipeline
Verhalten, das „sich von selbst erledigt“, wird auf ein Minimum reduziert
Alle Erweiterungen und Ausführungen werden explizit registriert und haben eine vorhersehbare Reihenfolge

Signaturbasierter Vertrag

Die Methodensignatur ist zugleich der API-Vertrag
ArgumentResolver übernimmt die Erzeugung der Eingaben, ReturnValueHandler die Verarbeitung der Ausgaben
Annotationsbasiertes Mapping und automatische Inferenz auf Basis von Konventionen sind ausgeschlossen

Controller-Unabhängigkeit

Controller hängen nicht von HTTP-/Transport-Typen ab
Es werden nur semantische Typen wie path.*, query.*, httperr.* verwendet
Das Ausführungsmodell bleibt dem Controller verborgen, aber die Herkunft der Eingaben wird über Typen explizit gemacht

Hauptfunktionen

Routing und Parameter

Unterstützung für Path Parameter (reihenfolgebasiertes Binding)
Query-Values-Utilities (Int-, String- und Boolean-Parsing)
Automatisches Binding von Body-DTOs

Antwortverarbeitung

Automatische Umwandlung von struct -> JSON über ReturnValueHandler
Automatisches Mapping von error -> HTTP-Statuscode
Semantische Fehlertypen wie httperr.NotFound, BadRequest usw.

Querschnittsthemen

Interceptor (PreHandle, PostHandle, AfterCompletion)
Integrierter CORS-Interceptor
IoC-Container auf Konstruktorbasis

Architektur

Getrennte Transport-Schicht (derzeit Echo, aber austauschbar konzipiert)
ORM-unabhängiges Design (Bun, GORM usw. können frei verwendet werden ⚠️ derzeit ist nur die Kompatibilität mit Bun bestätigt)

Stärken in groß angelegten Umgebungen

Da es nur eine einzige Instanz gibt, die die Ausführungsreihenfolge kennt, sinken die Kosten für die Nachverfolgung des Request-Flows.
Querschnittsthemen wie Logging, Transaktionen und Sicherheit werden ausschließlich in der Pipeline platziert, wodurch Anwendungsort und Zeitpunkt vorhersehbar sind. Dafür wird ein Teil der anfänglichen Produktivität geopfert, um langfristig wachsende Komplexität strukturell aufzufangen.

Was Spine nicht ist

Kein Ersatz für Spring/NestJS
Kein Framework zur Maximierung der Produktivität
Kein Framework für annotationsbasierte Automatisierung
Kein auf HTTP-Engine oder Router zentriertes Framework

Ein Projekt, das Unterstützung braucht

Spine ist noch kein fertiggestelltes Framework; viele Teile wurden bewusst in unfertigem Zustand veröffentlicht.
Es muss überprüft werden, ob sich die Struktur ausreichend gut erklären lässt und ob das Ausführungsmodell reale Probleme tatsächlich gut sichtbar macht.

Mitmachen

Dem Projekt auf GitHub mit einem ⭐️ folgen
Eigene Eindrücke oder Fragen nach dem Ausprobieren als Issue hinterlassen
Kritik, Vorschläge und Fragen zum Design in den Kommentaren teilen

Referenzlinks

Spine-Projekt: https://github.com/NARUBROWN/spine
Spine + Bun ORM User Demo: https://github.com/NARUBROWN/spine-user-demo

2 Kommentare

bsh998 2026-01-20

Es würde die Glaubwürdigkeit erhöhen, wenn Sie die KI-Beschreibung etwas überarbeiten und in etwas natürlichere Sätze umformulieren könnten.

narubrown 2026-01-20

Hallo, vielen Dank für das Feedback.
Meinen Sie damit, dass es wie von einer AI klingt – also der GeekNews-Beitrag?

Ich dachte, man müsse hier ursprünglich so schreiben ^^… Weil auch andere Beiträge so waren, habe ich ihn absichtlich in diesem Stil verfasst.

https://spine.na2ru2.me/ko/
Außerdem habe ich eine Website erstellt, auf der man Spine lernen kann.
Wenn Sie interessiert sind, schauen Sie sie sich bitte auch an, vielen Dank.