Topcoat 0.9 bringt Server-Push in das Rust-Full-Stack-Framework
Serguey Asael Shinder2 Min. LesezeitTopcoat, das umfassende Web-Framework, das im Umfeld des Tokio-Projekts entsteht, ist am 24. September in Version 0.9 erschienen. Neu ist Server-Push: Eine Seite kann eine WebSocket-Verbindung zum Server öffnen und Änderungen an der Oberfläche über eine langlebige Verbindung abonnieren. Ein Chatfenster oder eine Statusanzeige für Jobs rendert dadurch neu, wenn auf dem Server etwas passiert, und nicht erst, wenn jemand klickt. Angekündigt hat das Carl Lerche, der Tokio geschrieben hat und früher im Kernteam von Ruby on Rails war; das Frontend-Design verantwortet Julien Scholz.
Damit schließt die Version ein Rendering-Modell ab, das über mehrere Releases entstanden ist. Topcoat rendert standardmäßig auf dem Server. Kleine interaktive Teile schreibt man als Laufzeitausdrücke im Makro view! - eine typgeprüfte Teilmenge von Rust, die nach JavaScript übersetzt wird und im Browser läuft; ein Zähler oder ein Ladekreisel braucht so keinen Serveraufruf. "Shards" sind Komponenten, die der Server neu rendert, sobald sich ihre Argumente ändern. Seit 0.8 kann der Server beim Rendern ein Signal lesen und nur die davon abhängigen Fragmente neu laden; das zurückgegebene HTML wird so eingepasst, dass Fokus und Eingaben erhalten bleiben. Die Makros live! und emit! liefern mehrere Aktualisierungen aus einer Ansicht - so entstehen Lade-Skelette im Stil von Suspense und Fortschrittsanzeigen. Version 0.9 dehnt das vom ersten Seitenaufbau auf eine dauerhafte Verbindung aus.
Das zugehörige ORM Toasty bekommt ein Makro update!, das ein einzelnes UPDATE absetzt, ohne die Zeile vorher zu laden - das Hochzählen eines Zählers wird zu einer Anweisung. Dazu kommen Dokumentspalten, die unter PostgreSQL als JSONB abgelegt werden, und polymorphe Relationen, die als Rust-Enums mit den Annotationen #[shared(id)] und #[index(id)] beschrieben werden.
Was das bedeutet
Topcoat landet dort, wo auch Phoenix LiveView, Hotwire und Laravel Livewire stehen: HTML vom Server, ein schlanker Client und ein dauerhafter Kanal für Aktualisierungen. Der Unterschied: Die Schnipsel für den Browser prüft der Rust-Compiler, statt dass sie als JavaScript-Zeichenketten im Template stehen. Damit fällt eine ganze Klasse von Unstimmigkeiten zwischen Server- und Client-Code weg. Der Preis ist der übliche bei Server-Push: Jeder offene Tab ist eine Verbindung, die der Server halten muss. Die Kapazitätsplanung rechnet dann nicht mehr in Anfragen pro Sekunde, sondern in gleichzeitigen Sockets.
Es ist ein Framework mit Versionsnummer 0.x, und Lerche sagt offen, dass das Team noch herausfindet, wie es aussehen soll. Für Teams, die ohnehin Rust-Dienste betreiben, lohnt der Blick als Weg, eine interne Admin-Oberfläche neben ein bestehendes Tokio-Backend zu stellen, ohne einen eigenen JavaScript-Stack aufzubauen. Die im Beitrag geäußerte Begründung - klare Konventionen hälfen KI-Werkzeugen, mit weniger Fehlern funktionierenden Code zu schreiben - ist eine Behauptung und keine Messung; sie ist als Motiv des Autors zu lesen.