Refacto nécessaire côté API/Agrégateur/Itinérances

[Chatewgne]

Itinérances et étapes non publiées

Avoir à diffuser des randonnées enfants non publiées de randonnées publiées (ainsi que tous les objets qui leur sont liés) pose de plus en plus de soucis. C'est un état de "semi-publication" qui pose les soucis suivants :

1. Dans l'APIv2 : complexité du filtrage qui 1 - alourdit les performances et 2 - mène à une hétérogénéité du code et une maintenabilité difficile (sur certaines vues API, il manque des données qui ne sont pas publiées alors que si on poussait cette même logique de "semi-publication" jusqu'au bout elles devraient l'être), multiplication des cas particuliers qui ne font qu'augmenter
2. Dans l'Aggrégateur : à cause du point 1, nous sommes obligés de rajouter des requêtes API palliatives à plusieurs endroits, on se retrouve à faire du code spécifique sur une base qui se voulait générique
3. Dans Rando : les conséquence sur Rando (et tout autre appli se basant sur l'APIv2) sont à peu près les mêmes que celles sur l'Aggrégateur -> multiplication des cas particulier gérés de manière différente à chaque fois, perte d'homogénéité et de maintenabilité
4. Dans widget, le cas n'a pas été géré : les étapes ne s'affichent que si elles sont publiées, et leur objets liés ne sont pas récupérés si pas dispos dans la liste

Proposition :

• Créer une possibilité d'afficher tous les objets sur l'APIv2, qu'ils soient publiés ou pas (via une vue authentifiée) -> permet de tout télécharger et de créer un Aggrégateur identique au Geotrek Source
• Remplacer le mécanisme par un filtre "enfants_inclus" sur l'API des Treks ce qui permettra à Rando de faire la différence entre les objets de premier niveau / second niveau à afficher dans la vue liste, ou pas (idem sur les catégories)
• Faire les évolutions liées à ce changement sur Rando, Widget
• Transparent sur le fonctionnement pour les utilisateurs
• Attention API mobile ?

Tests unitaires en mauvais état

Les test unitaires de l'aggrégateur se basent sur des Mocks de l'APIv2 -> chaque réponse est écrite en dur. Cela découple complètement les évolutions de l'aggrégateur des évolutions de l'APIv2. Ca ne nous permet pas de remarquer en temps voulu si nous introduisons des bugs ou pas, en plus de rallonger le temps nécessaire à l'écriture des tests (le temps de dev est facilement doublé à chaque bugfix à cause de ça.) On vérifie mal si l'agrégateur s'adapte aux évolutions de l'APIv2 ou pas. Il faudrait ré-écrire la partie "initialisation" de tous ces tests pour se baser sur la sortie réelle de l'APIv2.

Architecture de l'Aggrégateur et conflits de variables

L'architecture se voulait le plus générique possible de sorte à ce que l'usage de l'aggrégation soit le plus facile possible (une aggrégation = une ligne de commande). En réalité un aggrégateur est composé de 6-7 Parsers, et il y a des conflits entre ces Parsers dont les variables internes se confondent les unes avec les autres, Il faut refaire le point sur le fonctionnement du système de mapping pour que chaque Parser ait un mapping indépendant, s'assurer que la configuration d'un Parser soit bien indépendante de la configuration des autres. Si non, on se retrouve à recréer autant d'Aggrégateurs qu'il y a de modèles pour contourner ce problème ce qui casse l’intérêt de l'architecture initiale et génère des requêtes supplémentaires. Il y a aussi des problèmes avec les valeurs qui doivent donner le pourcentage d'avancement, parfois on se retrouve avec des parsers qui chargent jusqu'à 300%, les valeurs affichées dans les logs n'ont pas toujours de sens.

[camillemonchicourt]

Oui c'était un contournement initial peut satisfaisant mais pour faire simple pour commencer, mais pas viable à long terme.

On a le même soucis avec les différentes passerelles (Apidae, Visorando, Outdooractive...) où ils ne peuvent pas récupérer les étapes des itinérances simplement.

Mais je ne suis pas certain que passer par une vue authentifiée soit une solution adaptée aux passerelles vers Apidae, Outdooractive, etc...

Il me semble plutôt qu'il faudrait un vrai système où on publie les étapes mais on indique ou non si elles doivent remonter uniquement comme enfants d'itinérances ou aussi comme des vrais randos (il y a les 2 cas selon les Geotrek).

Mais je vois pas encore bien clairement comment faire ça de manière solide et claire...