Backstage News

Dans les coulisses de Fleet, Partie I – Vue d’ensemble de l’architecture

Read this post in other languages:
English, 한국어, Deutsch, Русский, 简体中文

Nous avons récemment annoncé le lancement de Fleet, notre IDE nouvelle génération. Il est actuellement disponible en version preview privée et nous avons reçu de nombreux retours des premiers utilisateurs, qui nous ont permis de commencer à travailler à son amélioration en vue du lancement de sa version preview publique courant 2022.

En attendant, nous allons vous en dire plus sur la conception et le fonctionnement de Fleet. Nous avons préparé une série d’articles de blog afin de vous présenter toutes les facettes de Fleet, de la vue d’ensemble de son architecture aux détails concernant la gestion d’état, les analyseurs, les protocoles, l’extensibilité et même la conception de son logo. Nous espérons que vous apprécierez cette visite guidée au cœur de la salle des machines !

Quels sont les éléments constitutifs de Fleet ?

La première annonce de Fleet a donné lieu à des conversations intéressantes sur Twitter concernant les technologies utilisées. Certains pensaient qu’il reposait sur JavaScript et Electron. D’autres espéraient que cela n’était pas le cas. D’autres encore étaient soulagés qu’il ne s’agisse pas du « bon vieux Java ». Nous avons été surpris de voir toutes les conclusions qui ont pu être tirées à partir de simples captures d’écran !

Fleet repose en réalité sur une plateforme fiable et efficace : la JVM. Eh oui. La JVM. Pourquoi ? Car malgré certaines idées reçues, la JVM est en fait très performante. De plus, elle est multiplateforme, ce qui permet la prise en charge plusieurs systèmes d’exploitation.

La JVM ne se limite pas exclusivement au langage Java et vous n’êtes pas obligé d’utiliser Swing comme bibliothèque d’interface utilisateur (nous reviendrons plus en détail sur l’interface et l’utilisation de Skia par Fleet dans un prochain article). Elle permet d’utiliser différents langages, parmi lesquels Kotlin. Et c’est précisément avec Kotlin que nous avons bâti Fleet.

Toutefois, en tant que véritable IDE multilangage, Fleet lui-même est basé sur plusieurs langages. En effet, une petite part de Fleet, notamment le Fleet System Deamon, est construite avec Rust !

Architecture de Fleet

Maintenant que vous savez ce qui a été utilisé pour construire Fleet, passons à son architecture. Fleet comprend les composants suivants :

Examinons chacun de ces composants pour mieux comprendre leur rôle.

Frontend

S’il peut être tentant d’assimiler le frontend à l’interface utilisateur, il est en fait plus que cela. Il offre également des fonctionnalités comme :

  • L’analyse des fichiers
  • La mise en évidence des éléments de syntaxe et la saisie semi-automatique
  • La fonctionnalité d’éditeur

Fleet démarre en mode éditeur par défaut et offre la saisie semi-automatique et la navigation de base, ainsi que toutes les fonctionnalités que l’on peut attendre d’un éditeur puissant. Tout ceci est fourni par le frontend de Fleet.

Espace de travail

Comme son nom le laisse entendre, l’espace de travail permet de gérer tout ce qui se rapporte à la session de travail. Différents aspects, telles que la gestion de l’état, sont gérés par l’espace de travail. Cette fonctionnalité peut s’exécuter dans un processus avec Fleet ou en tant que processus distinct, selon qu’elle s’exécute localement sur la machine ou non, ce qui donne la possibilité d’exécuter un espace de travail sur un serveur distant.

Mode intelligent et backend

Comme mentionné précédemment, Fleet peut s’exécuter en tant qu’éditeur. Mais si vous recherchez des fonctionnalités plus avancées telles que la saisie semi-automatique du code, la navigation avancée, les refactorisations ou les inspections, vous pouvez utiliser le mode intelligent.

Ce mode intelligent prend en charge différentes options, notamment le moteur de traitement de code IntelliJ IDEA par défaut, les analyseurs personnalisés, et même les serveurs de langages, qu’ils soient basés sur les protocoles de serveur de langage (LSP) ou non.

Fleet System Daemon (FSD)

Ce composant écrit en Rust est notamment responsable des actions de build, de l’exécution du code et des commandes de terminal.

La combinaison de ces éléments permet de fournir une solution distribuée et évolutive. Plus tard dans cette série d’article, nous examinerons plus en détail les technologies ayant servi à créer chacun de ces éléments et les protocoles utilisés pour qu’ils communiquent entre eux.

Dans le prochain article, nous parlerons de la gestion d’état et verrons comment assurer la cohérence de tous ces services.

Restez à l’écoute !

Auteur de l’article original en anglais :

Delphine Massenhove

Hadi Hariri