Pour gérer vos consentements :

La stratégie "green coding" d'AXA passe par les API

Publié par Clément Bohic le - mis à jour à

Engagé dans une démarche d'exposition de ses pratiques de "green coding", AXA aborde le sujet des API, de la compression à la pagination.

Comment limiter l'empreinte environnementale du code ? L'an dernier, les équipes tech d'AXA avaient amorcé une série de publications à ce sujet.

Cinq volets sont parus jusque-là. Le premier abordait quelques fondements du "green coding", dont la matrice de référence d'ecoCode et des réflexions touchant à l'usage des ressources comme à la gestion du code en production. Le deuxième touchait à la gestion durable des données. Le troisième, à la compilation en image native. Le quatrième consistait en une revue globale des pratiques de "développement logiciel écoresponsable". Il y était question, entre autres, des sprites CSS, de la concaténation des fichiers JS, du lazy loading des images et de l'algo de tri rapide (quicksort).

Les API, de la compression à la pagination

Le cinquième volet traite des API. Il aborde en premier lieu le rate limiting (limitation du trafic). C'est-à-dire le contrôle de la fréquence à laquelle les clients ou les applications peuvent accéder à une API sur une période donnée. Une pratique qui contribue à réduire la consommation de ressources et donc l'empreinte carbone. À plus forte raison en encourageant la conception de systèmes plus économes en appels API, exploitant notamment les caches et les requêtes par lots.

Ces dernières, en englobant jusqu'aux jetons d'authentification, contribuent à diminuer la consommation de mémoire et de CPU, tout en réduisant le trafic réseau. En parallèle, elles favorisent un meilleur taux de compression et augmentent les chances de toucher le cache.

AXA évoque aussi l'usage de protocoles supportant le multiplexage, comme HTTP/2 et gRPC. Il mentionne également la pagination des API, qui permet de charger les données de manière incrémentielle. Avec elle, la charge peut être distribuée de façon plus équitable côté serveur et réduite côté client. On pensera à donner au client le contrôle de la taille des pages et à s'assurer que la pagination est gérée directement au niveau de la base de données (cela éviter de charger des données non nécessaires en mémoire). De même, l'usage de l'en-tête Last-Modified assurera que le serveur ne transmette que les données qui ont changé depuis la précédente requête.

Illustration © Seventyfour - Adobe Stock