Backstage News

Ein Blick in den Maschinenraum von Fleet, Teil 1 – Architekturübersicht

Wir haben kürzlich ein neues Produkt vorgestellt, an dem wir seit einiger Zeit arbeiten: Fleet, eine JetBrains-IDE der neuen Generation. Fleet befindet sich derzeit in der geschlossenen Preview und wir erhalten großartige Rückmeldungen von unseren Early Adoptern, die uns helfen, das Produkt zu verbessern und für eine öffentliche Preview im Lauf des Jahres 2022 vorzubereiten.

In der Zwischenzeit möchten wir gerne etwas mehr darüber erzählen, wie Fleet unter der Haube aufgebaut ist. In einer Reihe von Blogbeiträgen werden wir die verschiedenen Aspekte von Fleet im Detail beleuchten, von der Architekturübersicht bis hin zu Einzelheiten wie State-Management, Parser, Protokolle, Erweiterbarkeit und sogar die Entstehung des Logos. Wir wünschen Ihnen viel Spaß bei diesem Rundgang im Maschinenraum!

Wie ist Fleet aufgebaut?

Als wir Fleet zum ersten Mal vorgestellt hatten, fanden auf Twitter interessante Diskussionen über die verwendeten Technologien statt. Einige tippten auf JavaScript und Electron. Andere hofften, dass dies nicht stimmte. Manche waren froh, dass es nicht „altbackenes Java“ war. Es ist wirklich erstaunlich, wie viele Schlüsse ausschließlich auf der Grundlage von Screenshots gezogen werden können.

Die Wahrheit ist, dass Fleet auf einer zuverlässigen, leistungsstarken und wunderbaren Plattform basiert: JVM. Ja. JVM. Warum? Weil die JVM trotz einiger anderslautender Meinungen eine sehr performante Plattform ist. Hinzu kommt die Plattformunabhängigkeit, die uns die Unterstützung mehrerer Betriebssysteme erleichtert.

Allerdings ist die JVM nicht ausschließlich ein Host für die Programmiersprache Java. Es zwingt Sie auch keiner dazu, Swing als UI-Bibliothek zu verwenden (mehr über die UI und die Verwendung von Skia in Fleet folgt in einem der nächsten Beiträge). In Wirklichkeit können wir in der JVM eine Vielzahl von Sprachen verwenden – zum Beispiel Kotlin. Und genau damit haben wir Fleet entwickelt – mit der Programmiersprache Kotlin.

Als waschechte polyglotte IDE ist Fleet allerdings selbst auch polyglott. Ganz richtig – ein kleiner Teil von Fleet, insbesondere der Fleet System Daemon, ist in Rust geschrieben!

Die Architektur von Fleet

Nachdem wir nun wissen, in welcher Sprache Fleet entwickelt wurde, wollen wir uns der Architektur zuwenden. Fleet besteht aus den folgenden Komponenten:

Gehen wir nun im Einzelnen auf diese Komponenten ein, um ihre Aufgaben besser zu verstehen.

Frontend

Es ist zwar ein naheliegender Gedanke, dass das Frontend der Benutzeroberfläche entspricht – aber in Wirklichkeit handelt es sich um mehr. Neben der Benutzeroberfläche bietet das Frontend verschiedene weitere Funktionen:

• Datei-Parsing
• Syntaxhervorhebung und grundlegende Code-Completion
• Editor-Funktionalität

Fleet wird standardmäßig im Editormodus gestartet. In diesem Modus können Sie grundlegende Completion- und Navigationsfunktionen sowie weitere Features nutzen, die Sie von einem leistungsstarken Editor erwarten können. All dies wird vom Fleet-Frontend bereitgestellt.

Arbeitsbereich

Wie der Name schon sagt, ist der Arbeitsbereich der Ort, an dem Abläufe im Zusammenhang mit der Arbeitssitzung gehandhabt werden. Dazu gehören Aspekte wie das State-Management. Diese Funktionalität kann entweder im Fleet-Prozess oder als separater Prozess ausgeführt werden, je nachdem, ob sie lokal auf dem Computer ausgeführt wird oder nicht. Dadurch besteht die Möglichkeit, einen Arbeitsbereich auf einem Remote-Server auszuführen.

Smart-Modus und Backend

Wie bereits erwähnt kann Fleet als einfacher Editor ausgeführt werden. Wenn jedoch erweiterte Funktionen wie intelligente Code-Completion, erweiterte Navigation, Refactorings und Inspektionen benötigt werden, ist der Smart-Modus gefragt.

Der Smart-Modus kann auf eine Vielzahl von Optionen zurückgreifen, darunter die reguläre IntelliJ-IDEA-Codeengine, spezielle Analysemodule oder sogar Sprachserver (ob LSP-basiert oder nicht).

Fleet System Daemon (FSD)

Diese in Rust geschriebene Komponente ist verantwortlich für Build-Aktionen, das Ausführen von Code und von Terminalbefehlen sowie weitere Aktionen innerhalb der Umgebung, in der Fleet ausgeführt wird.

All diese Komponenten bilden zusammen eine verteilte und skalierbare Lösung. In separaten Beiträgen werden wir die Technologien, die diesen Komponenten zugrunde liegen, und die Protokolle, über die sie kommunizieren, im Detail beleuchten.

Im nächsten Beitrag sehen wir uns das State-Management an, um zu erfahren, mit welchen Methoden die Konsistenz zwischen all diesen Services sichergestellt wird.

Bleiben Sie also dran!

Autor des Original-Blogposts: