TaxHub v2 - Angular JS VS Angular ?

[Adrien-Pajot]

Bonsoir,

Je me demandais ce soir les raisons qui ont amené à choisir Angular JS par rapport à Angular dans TaxHub.
En effet, dans un contexte d'homogénéisation des applications GeoNature, serait-il intéressant de passer TaxHub sous Angular ? Cela permettrait notamment de mettre en place la dernière version du framework ?

Merci pour vos éclairements !

[camillemonchicourt]

Car avant Angular il y avait AngularJS. Et qu'on n'a pas mis à jour (ou plutôt refondu) TaxHub depuis.
@amandine-sahl avait initié une refonte de TaxHub en VueJS mais pas abouti.

[mvergez]

Je viens de découvrir qu'AngularJS avait arrêté le support en janvier 2022 (source : https://angularjs.org/). On pourrait discuter des futures technos ici non ?

Quelques propositions :

• Flask-admin ? (Faire attention à la pagination cf. Lourdeurs avec un grand nombre d'utilisateurs UsersHub#121)
• Angular (peut-être lourd pour cette application qui est beaucoup plus légère que GeoNature)
• Vue 3 ? React ?
• Autre ?

[camillemonchicourt]

En effet il y aurait une analyse à faire de la solution technique à utiliser pour la prochaine version de TaxHub.

• Flask-admin a été évoqué. A voir si il permet une solution ergonomique et de remplir l'ensemble des fonctionnalités comme les formulaires dynamiques des attributs qui sont différents d'une instance à l'autre
• Angular : surement trop lourd pour le besoin, mais à l'avantage d'être utilisé dans GeoNature donc limite la dispersion technologique et la nécessaire prise en main d'un autre framework par les développeurs de GeoNature
• Vue : des premiers tests réalisés. A l'avantage d'être plus simple et léger qu'Angular, tout en aillant une logique assez similaire
• React : potentiellement trop complexe pour le besoin et trop éloigné de la logique d'Angular donc nécessiterait plus de montée en compétence pour les développeurs de GeoNature
• Autre piste : Flask sans framework JS.

[jbdesbas]

Je trouve la dernière piste, Flask sans framework JS, assez séduisante. Ca simplifierait pas mal les déploiements et maintenances, mais ça me parait un chantier assez (trop ?) conséquent.

[bouttier]

À mon sens, la solution flask-admin est à privilégier pour 2 raisons majeurs :

• Faible coût de développement / maintenance :
  • une solution front serait beaucoup plus lourd à développer & maintenir
  • alors que les besoins fonctionnels de l’interface de TaxHub sont peu évolués
• Possibilité extrêmement simple d’intégrer TaxHub à GeoNature :
  • Facilité à gérer les mises à jour : mettre à jour GeoNature suffit
  • On s’affranchit des soucis inhérent à avoir 2 outils utilisant la même base de données, donc devant évoluer de manière synchrone avec les évolutions de la base de données

[mvergez]

On s’affranchit des soucis inhérent à avoir 2 outils utilisant la même base de données, donc devant évoluer de manière synchrone avec les évolutions de la base de données

Mais une des solutions ne serait-elle pas de rendre indépendant Taxhub et GeoNature du point de vue de la base de données ? Si on met de côté le chantier énorme que ça représente, est-ce une solution envisageable ?

[bouttier]

Le premier chantier, c’est déjà d’identifier une solution envisageable. À ce stade, je n’en ai pas (mais je suis biensûr ouvert aux propositions) ! Je rappelle que nous avons pleins de FK taxonomique dans GeoNature.

[mvergez]

Désolé, ma réponse n'était pas claire. Le chantier auquel je fais référence est celui de supprimer les FK taxonomiques de GeoNature pour séparer les bases de données entre elles. Mais cette solution demande d'abord une analyse de toutes ces FK, les contraintes, les joins réalisés dans GeoNature et ses modules etc. afin de passer par l'API de Taxhub directement.

[TheoLechemia]

Mon humble avis de gestionnaire de donnée du parc :

• il m'arrive à peu près un fois par semaine de devoir faire des exports de données ou je fais des jointures avec le schéma taxonomie. Je cherche de synonymes, le nombre d'obs par taxons pour telle zone, pour telle date etc etc... Si je devais écrire un script python interrogeant une API ce serait franchement très chiant !
• On stocke uniquement le cd_nom dans la synthese (et ailleurs) donc pour afficher une liste avec le nom fr, nom latin, groupe taxo, sur 200 lignes (pour ne pas dire 40K lignes), on fait une requête à l'API par ligne ??
• On perd l’intégrité référentielle entre les cd_noms et le schéma taxonomie, donc source d'erreur (pour avoir déjà mis les main dans une BDD sans FK, c'est assez rigolo ce que ça peut donner assez rapidement)

[DonovanMaillard]

J'ai bien compris que c'etait ni un scénario prévu ni un projet. Mais clairement pour administrer des données, je ne pourrais pas ne pas avoir le taxref dans ma BDD GéoNature. La première chose que je ferais serait de le réimporter dans une table custom. Pour ne pas avoir à apprendre le Python et aller taper sur des API ^^

[mvergez]

Merci à toutes et tous pour vos réactions et merci @TheoLechemia et @DonovanMaillard pour vos partages d'expérience.

Je me permets donc de partager ma courte expérience en tant que développeur et "déployeur" de GeoNature :

Il y a aujourd'hui une quarantaine (voire une centaine) de GeoNature d'installés (selon cette liste https://lite.framacalc.org/9efn-geonature-users) et cette liste grandit d'année en année ce qui fait qu'il y a au minimum une quarantaine de référentiels taxonomique français d'installés donc dupliqués donc évoluant ou pas librement et donc en retard ou divergeant du référentiel taxonomique livré par le MNHN chaque 6 mois/1 an à peu près.

Duplication

2.5Go par référentiel (car il y a toute la bdc_statut) multiplié par le nombre de GeoNature installés ça commence à faire pas mal de Go (~100Go soit quasi 2x la capacité d'un serveur qu'on déploie pour un client). Le stockage ne coûte pas très cher mais il consomme. Je ne compte pas les backups mais il faudrait multiplier ce chiffre au moins par 2.

(Ce n'est pas le sujet mais c'est la même chose avec le RefGeo et son Modèle Numérique de Terrain, voir les discussions ici si besoin : PnX-SI/GeoNature-citizen#321 (comment)).

Mais ce n'est pas le principal problème.

Mise à jour

Sur les quelques clients que nous avons côtoyés très peu se connectent en ssh au serveur et donc encore moins savent mettre à jour GeoNature (requis par exemple, si je ne me trompe pas, pour mettre à jour vers Taxref 15).

1er problème

Donc et c'est le principal problème pour moi : ils saisissent de la donnée erronée qu'ils ensuite envoient sur DEPOBIO. Donc OK les FK c'est bien mais la véracité des données est, selon mon humble expérience dans le domaine, primordiale. Dupliquer c'est potentiellement changer et erroner la donnée.

2nd problème

Mais il y en a une bonne partie qui font du SQL ce qui rejoint les propos de @TheoLechemia et @DonovanMaillard donc nickel.

Mais à défaut de mettre à jour Taxref de manière officielle, ils le font à la main (pas vu souvent mais possible) : comment ensuite se raccrocher au bon Taxref ? Comment ne pas faire de bêtises ? Qui valide la véracité des données mises à jour ?

Questionnement

C'est une vraie question que je me pose, je ne connais pas la réponse : dans le cas du module d'import : on a juste à saisir un cd_nom et un nom latin je crois et on importe dans la synthèse : donc si j'importe dans tel ou tel GeoNature j'ai possiblement une synthèse différente (si on s'en tient qu'à la taxonomie) ? C'est, je crois, le processus de téléversement des données dans DEPOBIO. Quid des FK ?

Les APIs

Je propose les APIs non pas par préférence mais parce qu'elles offrent la possibilité de par exemple avoir un seul TaxHub ou encore d'utiliser l'API du MNHN (https://taxref.mnhn.fr/taxref-web/api/doc) qui permet d'effectuer une requête en spécifiant la version de Taxref depuis la 2.0 par exemple.
Bien sûr, elles ne conviennent pas à toutes les utilisations et je comprends parfaitement les vôtres. Elles ne permettent pas de résoudre tous les problèmes, elles peuvent créer des problèmes de performance etc... Mais j'ai l'impression qu'elles présentent des avantages pour les problèmes cités ci-dessus.

Foreign Data Wrapper

On pourrait mettre le FDW dans la balance pour appeler finalement la même base de données. Je ne suis pas expert en FDW mais je vois plusieurs problèmes :

• Si une sécurité décente est mise en place : édition du pg_hba.conf de la base de données principale pour chaque nouveau client qui s'y connecte pour lui ouvrir les accès
• Pas de caching
• Pas de limite de requête tant en quantité qu'en type (pas de limit ou requête potentiellement mal optimisée)
• Dépendance à PostgreSQL voire à une version de celui-ci

Conclusion

Maintenant que nous avons partagé nos avis et nos expériences (n'hésitez pas à en partager d'autres), comment trouver des solutions qui peuvent répondre à toutes les problématiques citées dans ce ticket ?

Désolé pour le roman mais il fallait que je justifie ma réponse qui a suscité de "vives" réactions.

Merci beaucoup à vous d'avoir répondu et alimenté ce débat, c'est super intéressant d'avoir vos points de vue sur ces sujets.

[jbdesbas]

Passer par du FDW me parait une très bonne solution, et, il me semble, peut déjà être mis en place par ceux qui le souhaite :

• Pas de modification profonde de GeoNature/Taxhub (l’interrogation d'une table étrangère ou locale est transparente)
• Possibilité de centraliser localement le référentiel taxonomique (par ex au niveau d'une région, d'une fédération, etc.). Un référentiel peut donc être administré par une autorité compétente et partagé entre quelques instances.
• Transparent pour les administratrices ou administrateurs GeoNature
• Performances bien meilleures que par API.

Il ne me semble pas que le FDW pose problème entre différentes versions (pas trop éloignées) de PG ?

Le seul point négatif que je vois c'est les droits d'accès potentiellement compliqués à mettre en place, surtout pour les grosses structures ayant des politiques de sécurité poussées.

Niveau sobriété numérique, je ne suis pas sûr que l’exécution de centaines/milliers de requêtes HTTP(S) soit beaucoup mieux qu'une duplication du taxref (au doigt mouillé).

[camillemonchicourt]

Salut,

La duplication pose question en effet et n'est pas idéale, mais tout comme la duplication des GeoNature, la redondance avec les données dans l'INPN et les SINP régionaux, etc.
C'est à la fois une des faiblesses du projet et de son architecture, mais aussi une des clés de sa réussite et de son adaptation au besoin/contexte.

Je ne comprends pas tous les problèmes remontés, car saisir des données sur une ancienne version de Taxref n'est pas idéal mais ne créé pas de données erronées. Un CD_NOM correspondant à un taxon dans une version de Taxref ne peut pas correspondre à un autre taxon dans une autre version de Taxref.

Il est parfois aussi nécessaire d'ajouter marginalement des taxons temporaires dans Taxref le temps qu'ils soient intégrés dans une prochaine version de Taxref (cas réguliers DOM-TOM avec toutes les découvertes qui vont plus vite que Taxref, et une dizaine par an au PNE environ).

Comme évoqué précédemment, nous avons une volonté forte de garder une intégrité des données dans la BDD avec des clés étrangères, mais aussi la possibilité de requêter et traiter nos données directement en SQL dans la BDD, en lien avec Taxref.

Pour moi, la solution de passer par API Taxref seulement n'est pas satisfaisante pour les différentes raisons évoquées précédemment, à laquelle on peut ajouter les questions de dépendance à l'API Taxref, mais aussi d'adhérence à Taxref lui-même (on peut actuellement le remplacer par un autre référentiel comme dans cet exemple - https://si.ecrins-parcnational.com/blog/2019-05-geonature-atlas-gbif-jamaica.html).

Les FDW peuvent être une possibilité pour ceux qui veulent pas gérer Taxref, maitriser leur version, ajouter quelques taxons marginalement (pas notre cas), mais elle risque de poser 2 soucis :

• Impossibilité de faire des clés étrangères vers une table distante par un FDW
• Performances potentiellement fortement affaiblies

Si certains testent cette piste, faisable en l'état sans changement structurels de GeoNature ni TaxHub, n'hésitez pas à faire des retours.

Le point principal sur lequel je partage ton constat est la lourdeur et complexité de mise à jour de Taxref.
De notre côté, l'enjeu principal sur lequel nous souhaiterions avancer est celui de la mise à jour de Taxref, pour la simplifier et la rendre bien plus automatisable, du moins dans sa partie centrale.
Avec en lien avec cela, la possibilité d'intégrer TaxHub dans GeoNature (et ainsi en simplifier l'utilisation, l'installation et la mise à jour) ainsi que la gestion de plusieurs versions du référentiel (#306).

[mvergez]

Salut @camillemonchicourt,
Merci beaucoup pour ton retour ! Et merci également @jbdesbas pour le tien.

Je l'ignorais pour le cd_nom, merci de l'avoir précisé et désolé pour cette erreur.

Pour la dépendance à l'API de Taxref, il est possible de créer des interfaces (des genre de parsers) pour prendre en compte d'autres API donc pas forcément d'accord avec toi sur ce point là. Mais je comprends tes autres points.

Merci encore pour toutes ces infos

[gildeluermoz]

Bonjour à tous,
FDW est une bonne idée pour "disposer" de tables de référence. Cela offrirait des possibilités de comparaison, et éventuellement la mise en place de mécanisme d'évaluation de "l'actualité" du contenu e/out de mise à jour du référentiel interne à la base (taxonomie.taxref notamment)

Pour préciser les craintes de @camillemonchicourt, j'apporte quelques précisions quant à l'usage des FDW sur un sujet aussi central que la taxonomie dans GeoNature.
Cela mérite des tests en grandeur réelle car fdw peut potentiellement fortement impacter les performances concernant les requêtes utilisant des jointures.
Lorsque postgresql planifie une requête, il analyse les index disponibles et construit son plan de requêtage en fonction. Or il ne connait ni l'existence ni la nature des index présents sur la base distante dans le cas des tables en FDW.
Je me suis aperçu en creusant que lorsque tu fais des jointures entre des tables qui sont locales et des tables en FDW (dans l'atlas par exemple), les index ne sont parfois pas ou mal utilisés, conduisant à des sequential scan et dans ce cas, les perfs sont cata.
Si toutes les jointures sont faites entre tables distantes, la planification de la requête est confiée au serveur distant et les perfs sont bonnes. Si par contre il y a jointure entre table locale et distante, les index ne sont pas toujours utilisés. Et les perf tombent.
C'est à tester mais une simple requête ...

SELECT id_synthese 
FROM gn_synthese.synthese s 
JOIN taxonomie.fdw_taxref t ON t.cd_nom = s.cd_nom 
WHERE t.cd_nom IN (1,2,3,4)

...peut retourner de très mauvaises perfs si le planificateur de requête choisi un sequential scan sur la table fdw_taxref.
Comme dans taxref il y a beaucoup d'enregistrements et dans le cas de grosses instances avec beaucoup de données dans la synthèse, un scan séquentiel serait catastrophique.

[camillemonchicourt]

La refonte de TaxHub avec Flask-admin (intégrable à l'Admin de GeoNature ou non) a bien avancé, est intégrée dans la branche develop et est détaillée ici : https://github.com/PnX-SI/TaxHub/milestone/3

Aperçu sur : https://github.com/PnX-SI/TaxHub/blob/9196be1f1e2177a60f6ada45f373cc8c606d580e/docs/manuel-utilisateur.md

[camillemonchicourt]

Fait dans la version 2.0.0 de TaxHub avec la refonte de l'interface en Flask-admin, installable en tant qu'application autonome (standalone) ou intégré dans GeoNature :

---

---

---

Bonus : Ajout de nombreux filtres, de la possibilité de peupler des listes depuis un fichier CSV de cd_nom, suppression de bib_noms (simplifiant la gestion des taxons, des médias, des attributs, des listes, ainsi que les MAJ de Taxref)