Spectra

Spectra ist eine Marke für Gameserver-Hosting, für die wir das komplette Panel-Backend gebaut haben. Diese Fallstudie behandelt ein einzelnes, aber entscheidendes Teil dieses Puzzles: den nativen Desktop-Client für Administratoren. Es ist keine separate App, die neben dem Panel lebt - es ist eine weitere Hülle über demselben Kern, die mit demselben Backend spricht wie die Web-Version. Um zu verstehen, warum das eine Herausforderung war, muss man zuerst sehen, wie groß das System darunter ist.

Der Desktop-Client rendert keine hübschen Bildschirme über der Leere. Er steht auf einer vollständigen Plattform: Server-Provisioning, Leistungsverwaltung, Dateien, Datenbanken, Telemetrie, Abrechnung und Berechtigungen. Unsere Aufgabe war es, dem Administrator ein natives Fenster auf all das zu geben - ohne einen verpackten Browser und ohne Logik zu duplizieren, die ohnehin schon im Web-Panel lebte.

Ein Administrator von Gameservern schaut nicht einmal pro Woche ins Panel. Er hat es acht Stunden lang offen, neben der Konsole, dem Spiel-Client und dem Messenger. In diesem Modus ist ein weiterer Browser-Tab keine Bequemlichkeit, sondern ein fünftes Rad am Wagen: Er geht im Gedränge der Tabs verloren, hat kein eigenes Symbol in der Taskleiste, reagiert nicht auf Systemkürzel und sieht keine lokalen Dateien.

Wir wollten dieselbe Ansicht wie im Web geben, aber als App, die sich wie der Rest der Programme auf dem Desktop verhält. Eine harte Bedingung: kein verpacktes Chromium. Ein Client, der beim Start 200 MB Speicher hinzufügt, nur um genau dasselbe anzuzeigen, verfehlt sein Ziel, bevor er überhaupt fertig gestartet ist. Wenn der Administrator hier den größten Teil des Tages verbringen soll, muss die App leicht, sofort da und auf seinem System "zu Hause" sein und nicht ein weiteres Browserfenster, das ein Programm vortäuscht.

Das größte Missverständnis bei einem solchen Projekt ist der Gedanke, "es ist nur ein Panel". In Wirklichkeit ist das Panel eine dünne Schicht über einem Backend, das die schwere Arbeit erledigt: Es startet und stoppt Gameserver, weist Ressourcen zu, hält Datenbanken, streamt Logs und die Konsole live und überwacht Limits und Abrechnung. Dieses Backend ist die umfangreiche frozcore/frozmod-API - Dutzende von Endpunkten, Echtzeit-Ereignisse und ein Berechtigungsmodell, das entscheidet, wer was sieht und was er tun darf.

Der Desktop-Client muss mit genau derselben API sprechen wie das Web-Panel. Es gibt hier keine "vereinfachte Desktop-Version": Wenn der Administrator ein Speicherlimit eines Servers ändert oder eine Instanz neu startet, tut er das über denselben Vertrag, über den es auch das Web tut. Deshalb mussten wir, bevor auch nur ein einziger Bildschirm existierte, den Umfang dieser API verstehen und beherrschen - und das war der eigentliche Teil der Herausforderung, nicht das Aussehen des Fensters.

Die Domänenlogik - Autorisierung, das Servermodell, Leistungsbefehle, der Log-Stream, das Abbilden von Berechtigungen auf diese API - lebt in einer einzigen .NET-Bibliothek. Das Web-Panel und der Desktop-Client sind zwei Hüllen über diesem einen Kern, sodass eine Korrektur in einer Berechtigungsregel oder in der Behandlung eines Endpunkts an beiden Stellen gleichzeitig landet. Eine ganze Klasse von "im Web funktioniert es, auf dem Desktop kaputt"-Fehlern verschwindet einfach.

Avalonia zeichnet die Ansichtsschicht. Es ist kein Webview - die Steuerelemente rendern direkt über Skia, denselben Weg unter Windows und Linux, sodass die App auf beiden identisch aussieht. Nebenbei erhält sie echten Zugriff auf das Dateisystem, die Zwischenablage und Benachrichtigungen, den eine verpackte Seite nie hatte.

Das war der schwerste Teil. Das Spectra-Backend stellt Dutzende von Operationen bereit: Server-Lebenszyklus, Konsole, Dateien, Datenbanken, Aufgabenpläne, Backups, Benutzer und Berechtigungen, Ressourcentelemetrie. Damit der Desktop-Client nicht zu einem Gewirr von Aufrufen wird, haben wir die gesamte API in einen einzigen typisierten Client im Kern gehüllt - mit einer Stelle für Autorisierung, Wiederholungen und Fehlerbehandlung.

Da die Randbedingung "kein verpacktes Chromium" lautete, war Leistung kein Zusatz, sondern das Ziel. Avalonia zeichnet die Oberfläche direkt, ohne Browser-Engine im Inneren, sodass ein Binary mit dem vollständigen Panel einen Bruchteil dessen wiegt, was dieselbe Ansicht in Electron wiegen würde, und in einem Bruchteil einer Sekunde startet.

Hinzu kommt das, was ein Browser nie gegeben hat: echter Zugriff auf das Dateisystem (Serverdateien zeigen Sie direkt von der Festplatte an, ohne sie zuerst in einen Browser hochzuladen), Systemkürzel, native Benachrichtigungen und ein Symbol in der Taskleiste. Für jemanden, der den ganzen Tag im Panel sitzt, ist das keine Kosmetik, sondern eine tägliche Zeitersparnis.

Mit einem Kern, der den API-Client enthält, und einer Hülle auf Avalonia fügte sich das Ganze auf wiederholbare Weise zusammen. Entscheidend war, dass eine Quelle zwei eigenständige Binaries liefert, die auf beiden Systemen wirklich getestet wurden und nicht nur für beide kompilieren.

Der Administrator erhält ein Programm, das in einem Bruchteil einer Sekunde startet, sich wie jede andere App an die Taskleiste hält und genau die Daten zeigt, die das Web-Panel zeigt - denn darunter ist es derselbe Code und dieselbe API. Systemkürzel funktionieren, Dateien auf der Festplatte lassen sich auswählen, ohne sie zuerst in einen Browser hochzuladen, Konsole und Logs laufen live, und das Fenster geht nicht im Dickicht der Tabs verloren. Statt einer "Seite in einem Fenster" erhält der Administrator ein Werkzeug, das sich wie ein Teil seines Systems anfühlt.

Auf Spectras Seite ist der Gewinn ebenso konkret und langfristig. Eine Logik und ein API-Client statt zweier von Hand in Einklang gehaltener bedeuten, dass die Entwicklung der Plattform sich nicht mit der Anzahl der Hüllen multipliziert. Eine neue Berechtigungsregel, ein neuer Endpunkt im Backend oder eine Änderung im Servermodell landet im selben Commit im Web und auf dem Desktop. Eine ganze Klasse von Synchronisationsfehlern verschwindet, und der Desktop-Client hört auf, ein separates Projekt zur Pflege zu sein.

Am wichtigsten ist jedoch, dass der Desktop keine "Light-Version" ist. Er spricht mit derselben vollständigen frozcore/frozmod-API wie das Web-Panel, sodass der Administrator nie in den Browser zurückkehren muss, um eine Funktion zu erhalten, die der App gefehlt hat - denn es fehlte keine. Das ist der Unterschied zwischen einer verpackten Seite und einem echten, nativen Plattform-Client: Letzterer wächst mit dem Backend, anstatt hinterherzuhinken.