@Irone Salut,
Merci pour ton retour détaillé, je vois que tu soulèves plusieurs points importants qui méritent une réponse plus technique. Voici un exposé de mes choix architecturaux et des raisons derrière la suppression de la limite de 15 résultats.
1. Suppression de la limite de 15 résultats - Choix initial
La décision de retirer la limite de 15 résultats sur l'endpoint des groupes utilisateur ne s’est pas faite à la légère. L'objectif était d'améliorer l’ergonomie et la flexibilité de l'API, en permettant aux utilisateurs d’accéder à une quantité variable de données selon leurs besoins, notamment pour des scénarios où une pagination stricte serait contraignante (par exemple, dans des processus d’analyse ou d’exportation massifs). D'un point de vue technique, la modification consistait simplement à retirer la clause LIMIT 15 d’une requête SQL, ce qui semblait être une approche simple et directe pour répondre à un besoin fonctionnel.
2. Risque de requêtes N+1
Le point que tu soulèves concernant les requêtes N+1 est très pertinent, cependant je tiens à préciser que cette modification en elle-même n’introduit pas directement de requêtes N+1. Ce phénomène survient lorsque des relations entre entités sont mal gérées dans une base de données relationnelle, et que chaque entité liée entraîne une requête supplémentaire pour récupérer ses données associées.
Dans ce cas précis, l’endpoint de récupération des groupes ne devrait pas souffrir de N+1 si l’architecture des jointures est bien définie et que les données associées aux groupes (comme les membres ou les permissions) sont récupérées via des jointures SQL correctes dans la même requête. Si la structure des données et des relations est bien pensée, la suppression de la limite ne change pas la nature de la requête, qui reste une seule requête complexe avec des jointures multiples, mais pas un ensemble de requêtes itératives.
Cependant, si l’endpoint était basé sur une solution avec des requêtes itératives pour récupérer des données associées par utilisateur ou groupe, effectivement, on pourrait introduire un risque de N+1. C’est pourquoi, pour anticiper ce type de problème, il serait utile d’implémenter des stratégies comme l’utilisation de JOIN avec LEFT JOIN ou INNER JOIN (selon les cas) pour centraliser toutes les récupérations de données dans une seule requête.
3. Problèmes de performance - Gestion de la charge sur la base de données
Tu mentionnes un risque de surcharge de la base de données, ce qui est effectivement un point critique. La suppression de la limite peut entraîner des requêtes lourdes si le nombre de groupes par utilisateur devient élevé, surtout dans un système où la base de données n’est pas optimisée (ex : absence d'indexation ou de cache efficace).
À ce sujet, voici quelques points à considérer :
-
Indexation : Si la table des groupes n’est pas correctement indexée sur des colonnes fréquemment utilisées pour le filtrage ou le tri (par exemple, group_id, user_id, ou creation_date), cela peut ralentir considérablement les requêtes. L’ajout d’index supplémentaires sur ces colonnes spécifiques pourrait considérablement améliorer la vitesse des requêtes de récupération de groupes, même sans la limite.
-
Optimisation des requêtes : Le fait de retirer la limite de 15 résultats n’implique pas nécessairement que la requête devient plus coûteuse. Cela dépend de la façon dont la requête est structurée et des jointures effectuées. Si des optimisations telles que le EXPLAIN PLAN ou des outils de profiling de requêtes sont utilisés, on peut identifier les points de friction (tables non indexées, jointures inefficaces, etc.) et les corriger sans revenir à la pagination stricte.
-
Cache et requêtes répétitives : Un autre facteur qui peut minimiser la surcharge est l'implémentation d'un cache pour les résultats les plus fréquemment demandés. Par exemple, un cache au niveau de l’application (Redis ou Memcached) pourrait permettre de stocker les résultats de cette requête et d’éviter des appels répétitifs à la base de données, ce qui atténuerait le problème de surcharge.
4. Gestion des timeouts et des connexions
Tu fais bien de signaler les risques de timeouts et de saturation des connexions. Cela peut arriver si une requête devient trop gourmande en ressources ou si la base de données ne peut pas gérer un volume élevé de connexions simultanées.
-
Limitations au niveau de l'application : L'un des leviers pour éviter cela serait d’ajouter une limitation des appels API au niveau de l’application, pour éviter que des requêtes excessivement lourdes n'entraînent un crash. Par exemple, on pourrait introduire une limite de fréquence sur les appels de récupération de groupes ou prévoir un délai d'expiration pour éviter des requêtes bloquantes trop longues.
-
Optimisation des connexions DB : La gestion des connexions à la base de données pourrait également être améliorée en utilisant un pool de connexions efficace, ce qui permettrait de mieux gérer les connexions simultanées et d'éviter une saturation des ressources.
5. Pourquoi ce choix ?
Le choix de ne pas imposer une limite de résultats était motivé par un compromis entre flexibilité et simplicité d'usage. De nombreux cas d’usage, comme l’exportation ou l’analyse de données à grande échelle, bénéficient d’une approche sans limite stricte. D’un point de vue architectural, l’idée était de simplifier le code en évitant des appels API multiples, tout en gérant la pagination en interne ou via des mécanismes de cache.
Cela dit, je suis tout à fait conscient que des améliorations doivent être apportées en termes de gestion des performances et de sécurité pour que cette fonctionnalité puisse être utilisée de manière optimale dans tous les cas d’usage.
6. Solutions à court terme
-
Revenir à une limitation dynamique : Je propose de mettre en place une limite dynamique qui pourrait être ajustée en fonction de la charge système ou des types d’utilisateurs (par exemple, imposer une limite plus stricte pour les comptes de test ou de faible priorité).
-
Implémenter une pagination ou un système de "cursor-based pagination" : Cela permettrait de récupérer les groupes en plusieurs étapes sans surcharger la base de données, tout en offrant une solution flexible aux utilisateurs.
-
Audit de la base de données et des requêtes SQL : Un audit plus détaillé des requêtes et de l'indexation des tables est nécessaire pour identifier les goulots d’étranglement et optimiser les performances globales.
Ecrit par ChatGPT