Réduire les appels API dans une application Angular sans perdre en réactivité

Quand une application Angular prend de l’ampleur, le nombre d’appels API a tendance à gonfler sans qu’on y prête vraiment attention. Une simple action peut entraîner le rechargement de données déjà disponibles ou déclencher plusieurs requêtes alors qu’une seule suffirait. Pris isolément, chaque appel semble logique. Mais une fois additionnés, ils pèsent sur les performances, allongent les temps de chargement et donnent une impression de lourdeur.

L’enjeu n’est pas de traquer le moindre appel pour le supprimer. C’est de reprendre le contrôle sur le cycle de vie des données dans l’application.

Dans cet article, on va voir comment identifier les appels vraiment utiles, mutualiser les données entre composants, éviter les rechargements complets après chaque action et utiliser RxJS pour dompter les flux asynchrones.

Comprendre d’où viennent les appels superflus

Avant de chercher à optimiser quoi que ce soit, il faut observer ce que fait réellement l’application. L’onglet Réseau des DevTools est votre meilleur allié. Filtrez les requêtes XHR ou Fetch, puis naviguez dans l’application en effectuant les actions utilisateur habituelles. Vous allez vite repérer des comportements qui, sans être des bugs, méritent d’être questionnés.

On découvre souvent que plusieurs composants déclenchent le même appel en parallèle sans se concerter. Un header qui charge le profil utilisateur, un dashboard qui fait exactement la même chose, une sidebar qui recommence. Ailleurs, c’est une action toute simple qui provoque une cascade de rechargements. La suppression d’un élément peut entrainer le rafraîchissement complet d’une liste et d’un compteur.

Ces appels ne sont pas des erreurs de code. Ce sont des choix de développement qui se sont empilés fonctionnalité après fonctionnalité. Le premier principe à retenir est simple. Il suffit de recharger que ce qui a réellement changé.

Éviter les rechargements complets après chaque action

Le cas le plus fréquent d’appel inutile, c’est le rechargement intégral d’une ressource après une modification ou une suppression. On peut observer un schéma classique très répandu dans les applications. L’utilisateur supprime un élément, le backend répond 200, et immédiatement après, on rappelle l’API pour récupérer la liste complète. C’est propre, c’est rassurant, mais c’est rarement nécessaire.

Si le backend confirme que la suppression est réussie, pourquoi redemander des données qu’on possède déjà en mémoire ? On peut tout simplement retirer l’élément du tableau local.

L’opérateur tap (qui permet de faire un traitement annexe sans modifier la réponse de l’API) filtre le tableau local, et l’interface se met à jour immédiatement. Pas de deuxième appel, pas de chargement, pas d’attente. Pour une modification, le principe est identique : on récupère l’objet renvoyé par le serveur et on remplace l’ancienne version dans le tableau.

Cette approche fonctionne très bien quand l’action est simple et qu’il n’y a pas d’effets de bord complexes côté serveur. Si une suppression entraîne des recalculs en cascade qu’on ne maîtrise pas, un rechargement reste la solution la plus sûre.

Centraliser les données pour ne pas les redemander

Un autre problème courant survient quand plusieurs composants chargent la même ressource sans savoir que leurs composants voisins font pareil. C’est particulièrement visible avec les données utilisateur. Header, dashboard et sidebar lancent chacun leur propre appel GET /api/user/profile.

La solution consiste à déplacer la logique de chargement dans un service et à partager le résultat.

Tous les composants s’abonnent au même flux via userService.getUser(). Le premier déclenche l’appel API, les suivants reçoivent la donnée en cache sans toucher le réseau. L’opérateur shareReplay est la clé du mécanisme. Il transforme un Observable froid, qui exécute sa logique à chaque abonnement, en Observable chaud qui exécute une seule fois et partage le résultat. Le paramètre { bufferSize: 1, refCount: false } garantit que la dernière valeur est conservée même quand il n’y a plus d’abonnés actifs, ce qui évite de refaire l’appel lors d’un changement de route.

Maîtriser les flux asynchrones avec RxJS

RxJS (la bibliothèque utilisée par Angular pour gérer les flux de données asynchrones) fait partie intégrante d’Angular, et quelques opérateurs bien placés suffisent à éviter des dizaines d’appels inutiles. Le cas d’école, c’est le champ de recherche avec auto-complétion. Sans optimisation, chaque frappe déclenche une requête. L’utilisateur tape « article », et c’est six appels qui partent, dont cinq pour rien.

Voici comment dompter ce comportement :

debounceTime : attendre avant d’agir

Cet opérateur impose un délai de 300 millisecondes après la dernière frappe avant d’émettre une valeur. Si l’utilisateur tape rapidement, les valeurs intermédiaires sont ignorées. Ainsi une seule requête pour le mot complet au lieu d’une par caractère.

distinctUntilChanged : ignorer les doublons

Il compare la nouvelle valeur avec la précédente. Si l’utilisateur tape « test », efface le « t », puis le remet, la deuxième émission de « test » est bloquée. Simple, efficace, et ça évite des appels redondants.

switchMap : annuler ce qui n’est plus utile

C’est l’opérateur le plus puissant du lot. Il transforme une valeur en appel HTTP, et si une nouvelle valeur arrive avant la réponse, il annule purement et simplement l’appel en cours. Fini les résultats qui s’affichent dans le désordre parce qu’une vieille requête a mis plus de temps à revenir.

Trouver le bon équilibre au quotidien

Optimiser les appels API ne doit pas devenir une obsession. Le but n’est pas de supprimer toutes communications avec le serveur, mais de supprimer celle qui ne servent à rien. Un cache périmé affiché à l’écran fait bien plus de dégâts qu’un appel réseau supplémentaire.

Après une action critique comme une validation de commande ou une suppression en cascade, un rechargement complet depuis le serveur reste souvent le choix le plus judicieux. De même, si votre application fait vingt appels par session utilisateur, ce n’est probablement pas la peine de construire une architecture complexe pour en économiser trois.

Pour conclure, réduire les appels API dans une application Angular, c’est avant tout une question de réflexion avant de coder. Avant chaque fonctionnalité, demandez-vous si la donnée n’est pas déjà disponible ailleurs, si un rechargement complet est vraiment nécessaire, et si plusieurs composants ne font pas le même travail en parallèle.

Quelques opérateurs RxJS bien choisis, comme debounceTime, distinctUntilChanged, switchMap ou shareReplay, font le reste. Cette approche ne demande pas de refondre toute l’architecture.

Crédit photo : Jacob Wackerhausen