Stand und Roadmap
Was existiert, was entsteht, und der Weg zu einem vollständigen Framework. Stand v0.8.0, 19. Oktober 2026.
Die Bibliotheken heute
Jede Bibliothek im Workspace ist implementiert und getestet; Platzhalter gibt es keine. Der Workspace trägt eine gemeinsame Version, und das Changelog jeder Bibliothek führt darunter nur die eigenen Einträge.
| Bibliothek | Seit | Aufgabe |
|---|---|---|
webglue_spec | 0.1 | Der Request/Response-Vertrag und die Begriffe, ihn zu lesen |
webglue_router | 0.1 | Routing-Tabellen als Daten, Gruppen, HEAD und OPTIONS, prx routes |
webglue_test | 0.1 | Requests, Responses und Platzhalter-Handler für Tests, ohne Server |
webglue_server | 0.1 | Der Adapter-Vertrag, die Paritäts-Suite, prx webglue bench |
webglue_bandit | 0.1 | Adapter über Bandit: HTTP/1.1, HTTP/2, WebSockets |
webglue_wrangler | 0.2 | WebGlues eigener HTTP/1.1-Server; noch ohne HTTP/2 und TLS |
webglue_session | 0.2 | Session-Middleware über austauschbaren Store; ein In-Memory-Store |
webglue_static | 0.2 | Dateien aus einem Verzeichnis, sicher gegen Traversal |
webglue_pubsub | 0.3 | Topic-Broadcast auf pg, mit Adapter-Nahtstelle |
webglue_socket | 0.3 | Dauerhafte Verbindungen als Responses; RFC 6455 in beide Richtungen |
webglue_presence | 0.3 | Wer auf einem Topic verbunden ist, über Knoten hinweg |
webglue_cluster | 0.3 | Knotenerkennung: statische Listen, DNS |
webglue_pubsub_redis | 0.3 | Ein gemeinsamer Redis-Client und ein Redis-Pub/Sub-Adapter |
webglue_fragment | 0.4 | Server-Push von Daten und Markup-Fragmenten |
webglue_db | 0.4 | Ein Repository am Request, ausdrückliches Rollback |
webglue_validation | 0.4 | Prüft und wandelt Parameter, Header und Bodies |
webglue_view | 0.5 | Die Templates eines Projekts zu Funktionen kompiliert; ein Baum als Seite beantwortet |
webglue_content_negotiation | 0.7 | Der Medientyp einer Response, gewählt aus Accept und dem Angebot des Handlers |
webglue_params | 0.8 | Query-Strings und URL-kodierte Formular-Bodies in Maps gelesen |
webglue_server_csrf | 0.8 | Das Synchronizer-Token: in der Session gehalten, bei unsicheren Requests verlangt |
webglue_tailwind | 0.8 | Ein Stylesheet, gebaut von Tailwinds eigenständigem CLI, angepinnt und mit Prüfsumme; prx tailwind |
webglue_demo | 0.1 | Das begleitende Ticketsystem |
Zwei allgemeine Praxis-Bibliotheken kamen mit den Templates in 0.5 und liegen außerhalb von WebGlue, weil an ihnen nichts Web-förmig ist: quire liest Markup-Text zu einem Baum, und stencil kompiliert ein Template zu einer Funktion. webglue_redis heißt seit dem 30. September webglue_pubsub_redis.
Releases
- Fertigv0.1.0 (27. August) — das Kernmuster und minimales HTTP: Vertrag, Router, Test-Helfer, Server-Vertrag, Bandit-Adapter, Demo.
- Fertigv0.2.0 (24. September) — statische Dateien, Sessions, Wrangler und die Paritäts-Suite, Benchmarks.
- Fertigv0.3.0 (25. September) — das Echtzeit-Fundament: Pub/Sub, Sockets, Presence, Clustering, Redis.
- Fertigv0.4.0 (29. September) — Server-Push; die Bibliotheken für Datenschicht und Validierung kamen im selben Release.
- Fertigv0.5.0 (9. Oktober) — Templates und Views:
quire,stencilundwebglue_view, und eine Seite in der Demo, deren Ticket-Zeile dasselbe Template ist, das der Socket pusht. Vor der Datenschicht eingeschoben, wodurch sich jedes spätere Release um eins verschob. - Fertigv0.6.0 (9. Oktober) — die Datenschicht, veröffentlicht mit ihrer Demo: Suche nach Text und Status, und ein Audit-Protokoll.
- Fertigv0.7.0 (12. Oktober) — Content-Negotiation; die Demo beantwortet ein Ticket, eine Liste und ein Protokoll als Text, DXN oder JSON.
- Fertigv0.8.0 (19. Oktober) — was Lictors Registrierung brauchte: Formular-Bodies, CSRF-Schutz mit Synchronizer-Token und der Tailwind-Build; eine Session, die die eigenen Cookies des Handlers behält.
- In ArbeitAls Nächstes, für Lictors Login: die OAuth2-Server-Rollen — Authorization Code mit PKCE, und ein Token-Server mit undurchsichtigen, gehasht gespeicherten Tokens, Refresh-Token-Rotation, die bei Wiederverwendung die ganze Familie widerruft, Widerruf und Introspektion.
webglue_server_oauth2_tokenist gebaut und gemergt, aber noch nicht veröffentlicht; der Autorisierungsserver, die Client-Seite, die Lictor braucht, und eine Begrenzung der Login-Versuche folgen.
Was geplant ist
Seit dem 12. Oktober gibt es eine einzige Roadmap für alles im Praxis-Repository. Was WebGlue noch nicht gebaut hat, ist ein Backlog, keine Abfolge: Lictor bedient sich daraus Journey für Journey, und was übrig bleibt, wird nach Lictor WebGlues eigene Vervollständigung. Die Versionsnummern des alten Plans gelten nicht mehr; eine Version wird vergeben, wenn eine Phase endet.
- GeplantBackend — REST-Ressourcen mit OpenAPI aus denselben Definitionen, und
Accept-Language; GraphQL über Absinthe; CORS, Sicherheits-Header, Kompression und Basic Auth; OAuth2 und OpenID Connect in jeder Rolle, Session-Identität und Autorisierung; HTTP-Caching und Idempotenz; Tracing und Metriken; Jobs, Zeitpläne und Queues; Mail und Dateispeicher. Danach ein Kontrollpunkt: Backend vollständig. - GeplantFrontend — reaktive Zellen, Rendering und Hydration, der Browser-Build und die erste Insel, Fragment-Morphing und Live-Seiten, Client-Seiten, die als Prozess im Browser laufen, Client-Routing aus der Routing-Tabelle des Servers, Daten-Clients, Formulare, deren Regeln auf beiden Seiten laufen, für den Browser kompilierte Templates, Live-Reload. Danach: Frontend vollständig.
- GeplantFull Stack — OAuth2 aus dem Browser als öffentlicher Client, und Generatoren wie
prx webglue new. Fernziele: HTTP/3, gRPC. Danach: Framework vollständig.
Vorgeschlagen: Live-Views
Der Template-Vorschlag vom September beschrieb drei Bibliotheken, und alle drei sind gebaut. Sein vierter Teil nicht: eine Live-View, bei der ein Server-Prozess den Zustand einer Seite hält, sie mit denselben Templates rendert und die Änderungen pusht, die in die Seite eingearbeitet werden. Sie ist mit dem Frontend geplant, neben Client-Seiten mit denselben Callbacks, damit ein Bildschirm zwischen beiden wechseln kann.
Bekannte Lücken
- Noch nichts auf Browser-Seite: Seiten werden auf dem Server gerendert, und gepushte Fragmente werden nicht in sie eingesetzt.
- Wrangler hat kein HTTP/2, kein TLS und lehnt Request-Bodies mit Chunked-Encoding mit 501 ab.
- Statische Dateien haben noch keine Caching-Header, Ranges und kein
ETag. - Sessions haben nur den In-Memory-Store, ohne serverseitiges Ablaufen.
- Nur URL-kodierte Formular-Bodies werden gelesen; ein wiederholtes Feld behält seinen letzten Wert. CSRF hat das Synchronizer-Token, noch nicht das Double-Submit-Cookie für zustandslose Anwendungen.
- Tailwind wird für macOS und Linux auf x64 und arm64 geladen; musl- und Windows-Builds brauchen ein ausdrückliches
:binary. - Noch keine Bibliothek für Authentifizierung oder Autorisierung veröffentlicht; die OAuth2-Arbeit für Lictors Login läuft.
Ausprobieren
Noch nicht. WebGlue ist nicht veröffentlicht und braucht die Praxis-Toolchain, die ebenfalls noch nicht veröffentlicht ist. Wenn beides so weit ist, ist die Demo-Sitzung der Einstiegspunkt.