🔧Développement

Cette section décrit où trouver les différents composants pour le développement de la version distante de la plateforme MEDomics.

Nouvelle structure

Afin de séparer le composant client local du composant serveur backend, de manière à pouvoir exécuter l'un ou l'autre indépendamment et utiliser le serveur sans interface graphique (comme dans un terminal distant, via SSH), nous avons dû déplacer des fichiers et des fonctionnalités dans un dossier séparé, étiqueté backend dans le dépôt.

Express est maintenant au cœur de toutes les opérations backend, et vous pouvez trouver plus de détails sur son utilisation dans la Backend - Serveur sous-page ou sa propre sous-page, Points de terminaison Express.

De même, les parties du client qui ont été modifiées ou ajoutées pour s'adapter à ce nouveau mode d'utilisation seront décrites dans la Frontend - Client sous-page.

Activation/désactivation des modules distants

Beaucoup de modules n'ont pas encore été entièrement testés ou refactorisés pour une utilisation distante et ont donc été « verrouillés » derrière un écran blanc comme celui-ci :

Pour réactiver un module qui a été adapté à la nouvelle architecture, trouvez les REMOTE_READY_COMPONENTS et REMOTE_BLOCKED_COMPONENTS variables autour de la ligne 35 de renderer/components/layout/layoutContext.jsx, ainsi que le blockedInRemote défini à la ligne 150 de renderer/components/layout/layoutManager.jsx. Ces ensembles déterminent si un module est affiché ou affiche la page d'erreur, et peuvent donc être utilisés pour permettre l'accès aux modules une fois qu'ils sont prêts pour une utilisation en ligne.

Emballage et distribution

En utilisant les nouveaux fichiers GitHub Actions (situés sous .github/workflows), le serveur et le client peuvent désormais être empaquetés ensemble ou indépendamment :

• Un server-vX.Y.Z tag créera une release pour seulement le serveur NodeJS autonome, ainsi que des scripts pour le démarrer et l'arrêter.

  • Utilise serverRelease.yml pour démarrer le workflow, qui utilisera le package.json fichier dans le dossier backend pour rassembler les bonnes versions, puis pack_server.js pour créer des dossiers ZIP avec les éléments nécessaires (fichiers GO, fichiers Python, scripts de démarrage/arrêt, etc.) pour exécuter le serveur sur différentes plateformes.

• Un client-vX.Y.Z tag créera une release pour seulement le client Electron léger.

  • Utilise clientRelease.yml et electron-builder.client.yml (pratiquement comme c'était avant la séparation client/serveur mais sans aucune partie backend attachée).

• Un vX.Y.Z tag empaquettera les deux ensemble comme c'était le cas dans les versions précédentes locales uniquement.

  • Le chemin hérité, qui empaquette à la fois le serveur et le client ensemble (via automaticBuilding.yaml)