Das neue Backend des Open-Source-Community-Builders TSBOARD: GOAPI

Vor etwa 7 Monaten habe ich das TSBOARD-Projekt zum ersten Mal vorgestellt.

Damals waren sowohl Frontend als auch Backend in TypeScript geschrieben, und für den Betrieb des Backends wurde die Bun-Runtime verwendet.

Aus verschiedenen Gründen musste ich das Backend jedoch neu aufsetzen, und ich veröffentliche es nun in einem vom bestehenden TSBOARD-Projekt getrennten GitHub-Repository. Dieses neue Backend ist in Go geschrieben und wird in der offiziellen TSBOARD-Version zusammen mitgeliefert – in Form eines Binärprogramms.

---

Warum wurde das Backend neu erstellt?

• Die Bun-Runtime liefert wirklich eine hervorragende Performance. Aber trotz der Bezeichnung als All-in-One-Toolkit kann das Paketmanagement noch nicht mit npm mithalten.
• Deshalb waren für die Nutzung von TSBOARD zwei Runtimes nötig: Node.js und Bun. Das war umständlich und aus Sicht der Nutzer ebenfalls unbequem.
• Das Problem ist inzwischen behoben, aber in der Anfangszeit war es gravierend, dass es auf virtuellen CPUs nicht lief, sodass selbst ich als Entwickler es nicht auf anderen Servern bereitstellen konnte.
• Wie andere bereits angemerkt haben, könnte man das zwar mit Orchestrierung lösen, aber ich wollte die inhärenten Grenzen einer JS-Runtime überwinden, die letztlich an Single-Thread-Beschränkungen gebunden ist, und mehrere Threads nutzen.
• Ich brauchte mehr Typen. Mit TypeScript allein ließ sich dieses Bedürfnis nicht stillen.

Warum fiel die Wahl auf Go?

• Das neue Backend sollte 1) kompiliert werden, 2) die Speicherverwaltung möglichst selbst übernehmen und 3) keine Installation einer zusätzlichen Runtime oder Ähnlichem erfordern.
• Nach einigem Abwägen zwischen Rust, Kotlin, Python, PHP und Go habe ich mich für Go entschieden, das alle drei Bedingungen erfüllt – und für mich zugleich Neuland war. (Entschuldige, PHP.)
• Am meisten gefallen hat mir die Einfachheit von Go, und auch die Ähnlichkeiten zu TypeScript waren ein wichtiger Punkt bei der Entscheidung. Vor allem im Hinblick auf Concurrency- und Speicherverwaltung halte ich es im Vergleich zu den anderen Optionen für eine gute Wahl.

Wie war es, Go tatsächlich zu verwenden?

• Mir wurde klar, dass es auch bei Go keine Sprache gibt, die nur Vorteile hat. if err != nil { } ist zwar definitiv nötig, aber wirklich ziemlich lästig. Manchmal vermisse ich try catch finally.
• Vermutlich liegt es am Problem mit go-mysql-driver, aber in einer realen Entwicklungsumgebung mit dem Flaschenhals DB I/O lief es nicht so schnell, wie ich erwartet hatte. (Siehe dazu auch diesen Beitrag hier auf GeekNews: https://de.news.hada.io/topic?id=18048)
• Die implizite Anwendung von Interfaces fühlt sich für mich noch immer etwas ungewohnt an. Wollte man wirklich keine Keywords wie implements oder extends verwenden?
• Pointer waren dagegen sehr willkommen. Vor allem, weil man sich nicht um den Zeitpunkt der Speicherfreigabe kümmern muss!
• Die verschiedenen Typen, die einfachen, aber mächtigen Structs und die Slices sind einfach großartig. Besonders gut finde ich, dass es nur wenige Keywords gibt und man die Sprache schnell lernen und produktiv einsetzen kann.
• Dass man mit dem go-Keyword wie durch Magie Lightweight-Threads verwenden kann ...! Ich bin glücklich!

Mein Fazit nach dem Wechsel des Backends von einer JS-Runtime zu Go...?

• So etwas macht man besser nur einmal.
• Ich habe im Zuge des Benchmarkings des DB-I/O-Bereichs verschiedene Tests durchgeführt, und aus Performance-Sicht ist der Unterschied zwischen einer JS-Runtime und einem Go-Binary tatsächlich nicht besonders groß. Zum Beispiel verwendet auch die in JS häufig genutzte Bildbibliothek sharp letztlich die Bibliothek libvips, und es gibt nun einmal keine Webanwendung ohne DB I/O.
• Trotzdem denke ich, dass die Umstellung trotz aller Mühen die richtige Entscheidung war, und ich plane, das Backend künftig ausschließlich in Go weiterzuentwickeln.
  • Der Speicherverbrauch sinkt wirklich auf ein spürbar sinnvolles Maß. Natürlich ließe sich mit Rust noch weiter optimieren, aber dafür, dass man eine GC verwenden kann, bin ich mit diesem Niveau mehr als zufrieden.
  • Die Einfachheit der Sprache selbst ist wirklich unglaublich. Es gibt nur wenige Keywords, und die Nutzungsmuster sind größtenteils festgelegt, sodass sie leicht zu lernen ist. (Natürlich ist das gute Schreiben von Go noch einmal ein anderes Thema.) Besonders gut gefällt mir, dass eine große Vielfalt an primitiven Typen vorhanden ist.
  • Der für mich wichtigste Pluspunkt: Nach dem Kompilieren läuft es erst einmal, solange das Binary vorhanden ist. Für den Betrieb eines Backends zusätzlich noch etwas installieren und den Code darüber erneut ausführen zu müssen – darauf möchte ich künftig wirklich verzichten.

Wie verwendet man es?

• Windows wird leider nicht unterstützt. Das Binary muss unter Linux oder macOS ausgeführt werden.
• Auf dem verwendeten Server muss die Bibliothek libvips vorab installiert sein. Das Binary nutzt deren Funktionen zur Bildverarbeitung.
• Weitere Details habe ich in der Datei README.md beschrieben.

---

Es gibt noch vieles, was unzureichend ist, und ich freue mich weiterhin auf die wertvollen Anregungen anderer Entwickler. Dass ich bei der GeekNight-Veranstaltung so herumgedruckst habe, ärgert mich im Nachhinein sogar über mich selbst. Bug-Reports, Verbesserungsvorschläge oder auch ungewöhnliche Meinungen sind alle willkommen.

Der Dezember ist dieses Jahr besonders schwer, aber ich hoffe trotzdem auf eine bessere Zukunft im neuen Jahr. Vielen Dank, dass ihr diesen langen Text gelesen habt. Zum Schluss teile ich noch den Link zu den Release Notes von TSBOARD v1.0.0.

https://tsboard.dev/board/free/47

[angkr]

Ich habe es bei Damoang gesehen.
Das ist ein CMS, auf das man sich freuen kann. Vielen Dank.

[tsboard]

Ich war auch überrascht, dass es bei Damoang Leute gibt, die sich an mich erinnern. Haha, ich werde mich noch mehr anstrengen, um euren Erwartungen gerecht zu werden! 😊

[dongho42]

Sehr nützlich!

[tsboard]

Vielen Dank auch verspätet für den Kommentar! 😃

[jongyeol]

Die implizite Anwendung von Interfaces fühlt sich für mich immer noch etwas ungewohnt an. Wollte man wirklich keine Keywords wie implements oder extends verwenden?

Es gibt Vor- und Nachteile, aber als Vorteil fühlt es sich oft so an, dass man ohne Änderungen am Code von Standard-/externen Bibliotheken Implementierungen anderer Leute verwenden und Teile davon als ein von mir erstelltes interface behandeln kann. Ein bisschen wie FunctionalInterface in Java oder so, als hätte man Duck Typing auf eine kompilierte Sprache angewendet. Umgekehrt müsste man bei einem Ansatz, bei dem implements/extends zwingend deklariert werden müssen, zum Anbinden an ein von mir erstelltes interface zwischendurch einen Adapter implementieren.

Ein Nachteil ist, dass es beim Hinzufügen, Entfernen oder Ändern von Methoden im interface etwas unpraktisch ist, weil die Stellen, an denen Fehler angezeigt werden, im Vergleich zu anderen statisch typisierten Sprachen anders sind.

[tsboard]

Ach so, verstehe! Dass das so ein Vorteil ist, daran hätte ich gar nicht gedacht. Die Fehlermeldungen waren zum Glück, war es gopls? Jedenfalls hat die Go-Spracherweiterung von vscode sie gut erkannt, sodass ich Auslassungen oder fehlerhafte Implementierungen schnell finden konnte. Wenn ich mich noch etwas mehr daran gewöhnt habe, werde ich es irgendwann sicher auch besser nutzen können. Haha, danke für die Erklärung in den Kommentaren! Ich wünsche Ihnen ein frohes neues Jahr~!

[ifmkl]

Großartige Arbeit! Ich werde es auch auf meinem Testserver ausprobieren! Viel Erfolg auch im Neuen Jahr 2025!

[tsboard]

Vielen Dank! Testen Sie es gern, und wenn etwas nicht richtig funktioniert oder Sie Fragen haben, sagen Sie jederzeit gern Bescheid! Ich wünsche Ihnen ein frohes neues Jahr~!

[channprj]

Ich drücke die Daumen~ 👍🏻

[tsboard]

Vielen Dank für eure Unterstützung!!! Ich wünsche euch ein frohes neues Jahr~!

[zihado]

Ich drücke die Daumen!

[tsboard]

Vielen Dank!!! Frohes neues Jahr!!