# Développement ## 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](https://medomicslab.gitbook.io/medomics-docs/~/revisions/z0wFwbRqAmxlgbHR1M4e/tutorials/remote-medomics/development/backend-server) sous-page ou sa propre sous-page, [Points de terminaison Express](https://medomicslab.gitbook.io/medomics-docs/v1-fr/tutorials/medomics-a-distance/developpement/backend-serveur/points-de-terminaison-express-request). 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](https://medomicslab.gitbook.io/medomics-docs/v1-fr/tutorials/medomics-a-distance/developpement/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`)