Séparation frontend / backend & Dockerisation #2088

bouttier · 2022-10-24T14:07:28Z

Dans la version 2.11 de GeoNature, nous prévoyons un certain nombre d’évolution de nature à supprimer les liens existants actuellement entre le backend et le frontend.

Ces évolutions sont nécessaire à la mise en place d’une architecture Docker simple et classique. Cela veut dire :

Des images backend et frontend séparées
Une image frontend servant un frontend pré-buildé (buildé au build de l’image Docker)
Ce travail est initié sous forme de draft dans la PR Suppression du support des modules non-packagés #2081
Les images Docker pourront être généré automatiquement à chaque release, être diffusé publiquement, et servir aux tests automatiques.

Voici donc un résumé des évolutions prévus :

The text was updated successfully, but these errors were encountered:

jpm-cbna · 2022-10-25T16:10:59Z

Ajout de fichier package.json et package-lock.json au niveau du backend afin d’installer ses propres modules node.

Quels sont les besoins en package Node du backend ? Je n'avais pas réalisé qu'il y avait un tel besoin...

bouttier · 2022-10-25T16:41:13Z

Quels sont les besoins en package Node du backend ? Je n'avais pas réalisé qu'il y avait un tel besoin...

Actuellement la partie administration, mais qui peut être amené à disparaître avec la gestion front des permissions.

Pour la partie backoffice / flask-admin, il y a également des fichiers servis (jquery, bootstrap, …) mais c’est géré directement par flask-admin et pas par nous.

joelclems · 2022-10-28T08:58:18Z

Voici quelques réflexions que j'avais eu à ce sujet.

Passer par une api pour récupérer la config

J'avais commencé à travailler dessus sur la branche
https://github.com/PnX-SI/GeoNature/tree/feat/config2/

dans les grands principes il y avait un service de config qui récupérait la config depuis une api à l'initialisation de application

ce qui correspondrait dans la dernière version à cet endroit là:

GeoNature/frontend/src/app/app.module.ts

Line 64 in 8c10534

export function getModulesAndInitRouting(injector) {
- une seule api permettait de charger l'information sur les modules et sur la config pour ne faire qu'un seul appel au backend
dans toute l'application, les composants qui souhaitent accéder à la configuration doivent passer par le service de config.
- Par exemple:
  
  GeoNature/frontend/src/app/components/home-content/home-content.component.ts
  
  Line 57 in de12399
  
  this.appConfig = this._configService.config;
- ce qui implique de modifier le code du frontend dans sa quasi-intégralité
dans 95% des installation la route du backend est <url_de_geonature>/api, est ce que l'on peut proposer cette valeur par defaut ? et pour les installation de type de dev ou qui nécessite de changer cette api on doit ajouter un fichier config.json qui contient la valeur de cette api ????

Dossier `frontend/src/custom`

Afin d'éviter le plus possible à a voir à rebuilder le frontend

récupérer les élément de customisation (dossier frontend/src/custom) depuis le dossier static backend
- images d'accueil, logo
  - par exemple
    
    GeoNature/frontend/src/app/components/login/login.component.html
    
    Line 14 in de12399
    
    style="background: url({{appConfig.API_ENDPOINT}}/static/assets/custom/images/login_background.jpg) center 10% no-repeat;"
- html pour le texte texte d'accueil et le footer
  - (voir comment changer les composants custom introduction et footer pour qu'ils puissent récupérer le html depuis le backend)

Place du code des modules en frontend

L'idéal serait que l'installation du frontend du module se limite à un npm install <chemin vers le module>/forntend

Pour cela, il serait possible de :

faire un fichier package.json pour chaque module (contenant du code frontend)
- il faut bien choisir le nom du module dans le fichier package.json
  - on pourrait par convention prefixer par gn_module (comme gn_module_import, gn_module_export)
- la commande npm install /frontend va créer le lien symbolique vers le code frontend du module dans le dossier `geonature/frontend/node_modules/gn_module_...
- il faut bien préciser les chemin des sous-module dans les includes du fichier tsconfig.app.json

  "include": [
    "main.ts",
    ...
    "../node_modules/gn_module*"

d'où l'importance de bien choisir le nom des modules dans les fichiers package.json des module et de les préfixer en gn_module_

Migration d'une base existante dans un nouvel environnement

Dans le cas de la commande upgrade-modules-db on peut mettre à jour la base pour coller aux modules installés.

On peut aussi être dans le cas ou l'on a une base qui pssède déjà les modules, mais l'applicatif n'a pas ces modules installés.

Dans ce cas on pourrait rajouter des options à la commande d'installation des modules afin de pouvoir

installer seulement le module en backend (ce qui devrait correspondre à un pip install -e
installer seulement le module module en frontend (~ à un npm install /frontend)
installer seulement le module en base (nécessite d'avoir le module en backend, et serait l'équivalent de upgrade-modules-db mais pour un seul module)

bouttier · 2022-11-14T23:40:49Z

Merci Joël pour tes retours !

Gestion de la config : tout-à-fait d'accord sur de principe du mécanisme présent dans ta PR. Dans la manière de procéder, je pense qu'il faudrait mettre en place ce mécanisme (dans la 2.11 ?), puis progressivement supprimer tous les usages de AppConfig, et une fois terminée, supprimer les commandes GeoNature de génération de la config front (dans la 2.12 ?).
Frontend qui par défaut cherche l'API sur /api : bonne idée je trouve !
Intégrer la config à la route des modules : bof, c'est faire des routes spécifique au frontend plutôt que de concevoir une API. Il faut juste s'assurer que le frontend fasse les deux requêtes en parallèle et non séquentiellement.
Fichier custom dans le dossier statique backend : j'ai un peu du mal avec cette solution, ça me semble à l'opposé de l'objectif de séparation backend / frontend. Mais je n'ai pas vraiment de solutions : le build du frontend se termine par la collecte des fichiers statiques, mais il ne semble pas possible de relancer cette étape uniquement malheureusement. Éventuellement prévoir un dossier d'éléments de customisation qu'on gérerait indépendament du build, mais ce dossier resterait avec le front ?
En revanche, je n'ai pas de soucis à ce que le backend propose une route fournissant les messages à destination des utilisateurs (depuis la base, modifiable dans l'admin), qui serait exploité par le composant d'acceuil.
npm link : j'ai exploré cette piste mais je n'ai pas été entièrement satisfait, je me souviens notamment du fait que les liens sont globaux et donc compliqué de gérer plusieurs installes / version d'un même module. Mais je n'exclue pas qu'on y vienne un jour. Il faudra toutefois faire attention aux assets également mais sans doute rien d'insurmontable.
La commande install-gn-module s'occupe de tout tandis que upgrade-modules-db s'occupe spécifiquement de l'installation de la base. Pour le reste, il me semble superflu d'ajouter des commandes GN supplémentaires pour exécuter une ou deux simples commandes, qui sont détaillées dans la doc.

mvergez · 2022-11-16T14:17:28Z

Salut @bouttier et @camillemonchicourt !

Merci pour cette super issue.

Je viens juste d'y penser donc je le partage tout de suite : j'ai des interrogations sur cette ligne :

Intégration de TaxHub à GeoNature

En effet, dans le cas d'une installation de GeoNature Citizen chez un client, nous devons également installer Taxhub (pour la gestion des programmes qui sont basés sur des listes taxonomiques).
Donc si j'ai bien compris, vous souhaitez intégrer Taxhub dans GeoNature, ce qui voudrait dire que dans ce cas, si nous avons besoin d'installer Taxhub nous sommes obligés d'installer tout GeoNature ? Ou une installation séparée sera possible ?

Ce cas s'est produit avec plusieurs clients donc n'est pas forcément isolé.

Merci d'avance pour votre retour !

TheoLechemia · 2022-11-16T14:42:35Z

Non l'idée est bien de pouvoir toujours installer TaxHub indépendamment. Le but est que GeoNature intègre pleinement taxhub . Actuellement TaxHub est installé comme un sous module et on peut charger les modèles de TaxHub dans GN, mais on ne sert pas les routes de TaxHub dans GN.
L'idée est donc que GeoNature charge les blueprint de TaxHub pour servir toutes les routes sur quelquechose comme "/geonature/api/taxhub...", donc on a plus 2 services systemd, deux confs apache etc...
Pour le front, c'est un autre débat...

mvergez · 2022-11-17T11:12:25Z

Merci pour ta réponse @TheoLechemia !

A part effectivement pour se passer des services systemd, confs apache etc... Je ne vois pas vraiment l'avantage d'intégrer Taxhub à GeoNature.
Surtout dans un contexte de dockerisation ou Taxhub deviendrait un service comme GeoNature dans docker-compose. Et en plus si on met flask-admin, il n'y aura pas vraiment de frontend séparé donc tout pourra être compris dans une seule image docker donc ce serait juste quelques lignes à ajouter au docker-compose. Et pas de souci de systemd confs apache etc....

Après c'est mon avis personnel mais :

Chaque application devrait avoir ses propres responsabilités et le découpage GeoNature/Taxhub/UsersHub allait dans ce sens
Intégrer Taxhub à GeoNature accentuerait encore plus la dépendance entre les 2 applications donc j'imagine plus de temps lors des mises à jour de GeoNature etc... Moins de liberté dans le choix des versions de librairies par exemple (même si aujourd'hui c'est le cas car on importe les modèles...)
Si j'ai bien compris, il y aurait alors 2 fonctionnements : on appelle l'API de GeoNature pour accéder à Taxhub mais quand on a pas GeoNature alors on appelle l'API de Taxhub. Par exemple : dans le cas de Citizen sans GeoNature : API Taxhub, dans le cas de l'atlas avec GeoNature : API GeoNature. ça pourrait porter à confusion.
Et effectivement, si demain on souhaitait faire un frontend pour Taxhub car flask-admin n'est pas suffisant alors ça complexifie le problème.

Merci d'avance pour vos retours et j'espère n'être pas complètement à côté de la plaque !

lpofredc · 2022-11-17T14:17:01Z

Je confirme le besoin d'un taxhub autonome et indépendant ;) Actuellement utilisé dans plusieurs applications chez nous: BiodivTerritoires et Oiseaux de France en plus des instances GeoNature-citizen et GeoNature-atlas.

camillemonchicourt · 2022-11-17T14:25:01Z

Oui oui on a bien ces cas en tête et il n'est pas prévu de ne pouvoir installer TaxHub qu'avec GeoNature, mais de pouvoir l'intégrer pour simplifier l'architecture, éviter de dupliquer son installation, et surtout car dans ce contexte TaxHub et GeoNature ont la même BDD, donc ils sont de fait dépendants.
Voir PnX-SI/TaxHub#297 (comment)

mvergez · 2022-11-17T14:49:43Z

Merci beaucoup pour vos retours !
J'ai répondu directement à l'issue que tu as mentionné @camillemonchicourt, ce sera plus simple, merci !

bouttier · 2022-11-17T14:59:37Z

Je remet en avant le fait qu’en l’état, TaxHub a beau être déployé à côté de GeoNature, il n’en reste pas moins installé également dans le venv de GeoNature (pour utiliser les modèles taxonomique). L’installer qu’une fois et pas 2 est donc plutôt un gain de temps !

Cette intégration dans GeoNature restant soumise à la refonte du front en flask-admin, je pense que nous nous dirigerons dans un premier temps vers une Dockerisation de TaxHub dans sa forme actuelle.

Je réaffirme comme dit par Théo & Camille la volonté de garder la possibilité de déployer TaxHub sans GeoNature (comme les nomenclatures par exemple).

mvergez · 2022-11-17T15:29:17Z

Je suis d'accord avec vous, qu'en l'état, il vaudrait mieux l'installer avec. Tout en, comme vous l'avez dit tous les 3, le gardant installable sans GeoNature. Car, effectivement, ils sont dépendants par la base de données et Taxhub est installé dans le venv.

Avec la réponse que j'ai écrite dans le sujet PnX-SI/TaxHub#297 (comment), tout cela me fait donc me poser, peut-être à tord, la question suivante : ne se dirige-t-on pas vers un rassemblement de toutes les applications dans GeoNature qui pourrait peut-être à terme alourdir sa maintenance et ses mises à jour ? Car je me dis naïvement, qu'en séparant les choses, chacune peut évoluer indépendamment, au niveau contenu du code (tout en conservant bien sûr les liens que sont les API Rest), technologies employés (backend, frontend, bdd), librairies utilisées etc... Et cela permet aussi de séparer la charge de travail entre les différentes applications.

Mais peut-être que ces discussions sont à faire autre part ? J'ai lancé un gros sujet, j'en suis désolé s'il n'avait pas sa place ici.

Merci beaucoup en tout cas pour vos retours !

camillemonchicourt · 2022-11-17T19:21:23Z

Les 2 outils garderont leur dépôt, leur cycle de vie et de release, etc, mais il sera possible d'installer TaxHub directement avec GeoNature, comme une dépendance. GeoNature est de fait déjà dépendant de TaxHub car ils partagent la même BDD.

joelclems · 2022-11-18T09:26:40Z

Salut Elie et merci pour ta réponse

La méthode d'y aller progressivement me semble bonne, déjà pour tester sur quelques éléments (page home de geonature) pour montrer que cela marche

API

on peut faire deux api c'est peut être plus simple à maintenir

en gardant l'api modules qui renvoie principalement les infos de gn_commons.t_modules et celles sur le cruved
et et faisant une api config qui renvoie les infos contenus dans les fichiers de config .toml de geonature et des modules

cette dernière pourrais renvoyer un dictionnaire de la forme suivant ou la config des module aurait pour clé le code du module

... (config de geonature
OCCTAX: { ... }

SYNTHESE: { ... }
OCCHAB:

Assets

concernant les images et plus globalement les assets, dans le module gn_module_monitoring, j'avais fait en sorte de passer les assets des sous-module dans le dossier static de geonature (<static>/monitoring/<code_du_sous_module>/...

cela avait l'avantage de ne pas avoir à recompiler le frontend à chaque installation de sous-module

l'idée est que le frontend est là pour rendre disponible les infos qu'il va demander au backend

c'est plus facile de charger ou changer un fichier image dans static
- on pourrais imaginer de pouvoir personnaliser geonature depuis l'interface
en poussant un peu on pourrait même stocker ces images custom dans la base
- je ne sais pas au niveau des performances mais ça pourrais simplifier les montée de version ou les migrations sur un nouveau serveurs
il faut bien sur distinguer
- les assets pour la personnalisation (image d'accueil, logo)
- des assets qui servent au fonctionnement (icones, etc...) et qui ne sont pas destinés à être personnalisable, et qui eux devraient rester dans le frontend

commande d'installation

Le but est de pouvoir mettre le frontend et le backend dans deux docker différents
Pour la partie installation du frontend des modules on pourrait

créer script qui va effectuer ce qui était fait par la commande geonature install-gn-module
- lien symbolique vers frontend/external_modules/<module_code>
- installer les dependances s'il y en a dans le package.json du module (ou package-lock.json
- (voir définir une commande npm qui elle va appeler ces script d'installation)
ajouter une commande dans le package.json de geonature qui permettrait de jouer ce script pour un module
- npm install_gn_module <chemin vers le module> <module_code>
- je ne sais pas bien ce qui est possible dans ce domaine, mais ça me semble élégant

on pourrait garder la possibilité d'appeler npm install_gn_module <chemin vers le module> <module_code> dans la procédure de la commande geonature install-gn-module en le rendant optionnel

cela permettrait

dans le cadre d'une dockerisation séparée
- de pouvoir se passer de l'installation de l'application geonature dans le docker frontend (voire de l'installation de python)
dans le cadre d'une installation classique
- de pouvoir installer un module (backend et frontend) en une seule commande geonature install-gn-module et de garder cette simplicité de n'avoir à faire qu'une seule commande

camillemonchicourt · 2023-09-18T15:09:46Z

Cette séparation a été intégrée dans la 2.12.
Et la dockerisation est désormais disponible depuis la 2.13.1.

PnX-SI deleted a comment from jpm-cbna Oct 25, 2022

bouttier mentioned this issue Oct 27, 2022

Suppression du support des modules non-packagés #2081

Merged

camillemonchicourt mentioned this issue Oct 31, 2022

Packager le module PnX-SI/gn_module_ZH#7

Closed

bouttier mentioned this issue Nov 10, 2022

Feat/remove install module command #2130

Closed

This was referenced Nov 14, 2022

Ajout de la commande upgrade-modules #2134

Merged

Remove templating of tsconfig and tsconfig.app #2073

Merged

bouttier mentioned this issue Dec 12, 2022

Dockerisation #2206

Open

3 tasks

camillemonchicourt mentioned this issue Dec 12, 2022

Configuration dynamique du frontend #2205

Closed

3 tasks

bouttier mentioned this issue Jan 30, 2023

Gestion des fichiers statiques et des médias #2306

Closed

camillemonchicourt added this to the 2.12 milestone Feb 5, 2023

bouttier modified the milestones: 2.12, 2.13 Mar 27, 2023

camillemonchicourt closed this as completed Sep 18, 2023

jacquesfize mentioned this issue Mar 6, 2024

mixed content (invocation d'une API en http depuis une page https) #2936

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Séparation frontend / backend & Dockerisation #2088

Séparation frontend / backend & Dockerisation #2088

bouttier commented Oct 24, 2022 •

edited

Loading

jpm-cbna commented Oct 25, 2022

bouttier commented Oct 25, 2022

joelclems commented Oct 28, 2022 •

edited by bouttier

Loading

bouttier commented Nov 14, 2022 •

edited by camillemonchicourt

Loading

mvergez commented Nov 16, 2022

TheoLechemia commented Nov 16, 2022 •

edited

Loading

mvergez commented Nov 17, 2022

lpofredc commented Nov 17, 2022

camillemonchicourt commented Nov 17, 2022

mvergez commented Nov 17, 2022 •

edited

Loading

bouttier commented Nov 17, 2022

mvergez commented Nov 17, 2022

camillemonchicourt commented Nov 17, 2022

joelclems commented Nov 18, 2022

camillemonchicourt commented Sep 18, 2023

Séparation frontend / backend & Dockerisation #2088

Séparation frontend / backend & Dockerisation #2088

Comments

bouttier commented Oct 24, 2022 • edited Loading

jpm-cbna commented Oct 25, 2022

bouttier commented Oct 25, 2022

joelclems commented Oct 28, 2022 • edited by bouttier Loading

Passer par une api pour récupérer la config

Dossier frontend/src/custom

Place du code des modules en frontend

Migration d'une base existante dans un nouvel environnement

bouttier commented Nov 14, 2022 • edited by camillemonchicourt Loading

mvergez commented Nov 16, 2022

TheoLechemia commented Nov 16, 2022 • edited Loading

mvergez commented Nov 17, 2022

lpofredc commented Nov 17, 2022

camillemonchicourt commented Nov 17, 2022

mvergez commented Nov 17, 2022 • edited Loading

bouttier commented Nov 17, 2022

mvergez commented Nov 17, 2022

camillemonchicourt commented Nov 17, 2022

joelclems commented Nov 18, 2022

API

Assets

commande d'installation

camillemonchicourt commented Sep 18, 2023

bouttier commented Oct 24, 2022 •

edited

Loading

joelclems commented Oct 28, 2022 •

edited by bouttier

Loading

Dossier `frontend/src/custom`

bouttier commented Nov 14, 2022 •

edited by camillemonchicourt

Loading

TheoLechemia commented Nov 16, 2022 •

edited

Loading

mvergez commented Nov 17, 2022 •

edited

Loading