Trace 5 - Optimisation VRS API et agrégat MongoDB

Trace 5

Optimiser GET /check/list dans la VRS API

Agrandir

La Trace 5 ci-contre présente la comparaison entre le chemin original de GET /check/list et le chemin optimisé ajouté dans la VRS API ; elle a sa place dans le sujet du stage parce que les exports Cockpit dépendent d'abord d'une recherche de données fiable et suffisamment rapide. Si la recherche des checks est lente, l'export reste lent même si le moteur de génération du fichier est amélioré.

1. La première ligne compare le temps total moyen de la recherche avant et après optimisation.
2. La ligne "Agrégat OK-starts" montre le gain principal sur l'agrégat MongoDB le plus coûteux.
3. La dernière colonne explique les changements techniques : filtres plus tôt, moins de lookups et pagination avant les étapes lourdes.

Dans la Trace 5, le mode optimisé est activé par défaut avec useOptimized=1 ou avec le header x-use-optimized-query: true, tout en conservant le chemin original comme fallback. Cette séparation permet de comparer les deux versions sans perdre la possibilité de revenir à l'ancien comportement. Le savoir-faire faire évoluer un système existant sans rupture apparaît ici : l'objectif n'était pas de remplacer brutalement toute la route, mais d'introduire une version mesurable, contrôlable et désactivable si nécessaire.

Le premier changement important consiste à réécrire certains filtres avant de lancer l'agrégat. Par exemple, un filtre du type post.platformRef.id est transformé en filtre direct sur post après recherche des places correspondantes. Cela permet à MongoDB de filtrer plus tôt sur les checks, au lieu de réaliser un $lookup massif puis de filtrer après coup. Dans la Trace 5, ce point correspond au savoir-faire réduire le volume de données le plus tôt possible, car chaque document écarté au début évite des enrichissements inutiles ensuite.

Le deuxième changement consiste à ranger les filtres selon leur coût : firstFilters pour les filtres applicables directement sur les checks, postFilters pour ceux qui nécessitent le lookup du poste, puis endFilters pour les filtres dépendant d'autres enrichissements. Le tri, le skip et le limit sont ensuite appliqués avant les lookups les plus lourds. Cette partie illustre le savoir-faire optimiser l'ordre d'exécution d'une requête : la même donnée finale est recherchée, mais le moteur fait moins de travail pour y arriver.

Enfin, la route optimisée limite le populate automatique. L'ancien chemin exécutait l'agrégat puis relançait un populate Mongoose plus large. Le nouveau chemin récupère un résultat brut, puis recharge seulement les templates nécessaires. La Trace 5 relie ainsi quatre étapes : mesure avec le profiler, changement de structure de l'agrégat, réduction des lookups, puis comparaison avant/après. C'est une trace technique forte parce qu'elle relie une décision de code à un gain visible pour Cockpit.