Closed bouttier closed 1 year ago
jpm-cbna
commented
2 years ago
- Ajout de fichier
package.jsonetpackage-lock.jsonau 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
commented
2 years ago 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
commented
2 years ago Voici quelques réflexions que j'avais eu à ce sujet.
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à: https://github.com/PnX-SI/GeoNature/blob/8c105340915fa87bb803045e1b1a18513f24a0a3/frontend/src/app/app.module.ts#L64
dans toute l'application, les composants qui souhaitent accéder à la configuration doivent passer par le service de config.
dans 95% des installation la route du backend est
frontend/src/customAfin d'éviter le plus possible à a voir à rebuilder le frontend
frontend/src/custom) depuis le dossier static backend
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 :
package.json pour chaque module (contenant du code frontend)
package.jsongn_module_import, gn_module_export) 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_
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
upgrade-modules-db mais pour un seul module)bouttier
commented
2 years ago Merci Joël pour tes retours !
AppConfig, et une fois terminée, supprimer les commandes GeoNature de génération de la config front (dans la 2.12 ?).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.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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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 :
Merci d'avance pour vos retours et j'espère n'être pas complètement à côté de la plaque !
lpofredc
commented
2 years ago 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
commented
2 years ago 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 https://github.com/PnX-SI/TaxHub/issues/297#issuecomment-1291654478
mvergez
commented
2 years ago Merci beaucoup pour vos retours ! J'ai répondu directement à l'issue que tu as mentionné @camillemonchicourt, ce sera plus simple, merci !
bouttier
commented
2 years ago 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
commented
2 years ago 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 https://github.com/PnX-SI/TaxHub/issues/297#issuecomment-1291654478, 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
commented
2 years ago 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
commented
2 years ago 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
on peut faire deux api c'est peut être plus simple à maintenir
modules qui renvoie principalement les infos de gn_commons.t_modules et celles sur le cruvedconfig qui renvoie les infos contenus dans les fichiers de config .toml de geonature et des modulescette 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: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
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
frontend/external_modules/<module_code>package.json du module (ou package-lock.jsonajouter 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> 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
geonature install-gn-module et de garder cette simplicité de n'avoir à faire qu'une seule commandecamillemonchicourt
commented
1 year ago Cette séparation a été intégrée dans la 2.12. Et la dockerisation est désormais disponible depuis la 2.13.1.
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 :
Voici donc un résumé des évolutions prévus :
tsconfig.jsontsconfig.app.jsonapp.config.tsau profit d’une récupération de la configuration dynamiquement à partir de l’API. L’URL de l’API devra bien évidemment continuer à être connu par le backend, mais elle sera fourni dans un fichier json, et non typescript, de manière à ne pas nécessité de rebuild du front pour la définir.external_moduleset remplacement par un lien symbolique vers le frontend des modules dans un sous-dossier du dossierfrontendde GeoNature. Nécessaire pour des raisons techniques, et pour une meilleur gestion des dépendances node.upgrade-modules-dbpour compléter la tablet_modules& installer / mettre à jour le schéma de base de données des modules. Actuellement, ces opérations portant sur la base de données sont fait à l’installation du module, ce qui est incompatible avec la création d’une image backend alors que la base de données n’existe pas encore.create_appt_modules(en lien avec le point précédent)ID_APPau démarrage, se contenter du code applicationpackage.jsonetpackage-lock.jsonau niveau du backend afin d’installer ses propres modules node. Actuellement, les besoins du backend sont renseigné au niveau du frontend, et le dossiernode_modulesdu frontend est symlinké au niveau du backend.