Introduction aux limites de débit

Cet article accompagne une vidéo de la chaîne YouTube ShopifyDevs. Dans la première partie de cette série de trois articles, Zameer Masjedee, ingénieur solutions pour Shopify Plus, présente certaines bonnes pratiques pour traiter les limites de débit via l'exemple concret d'une application privée dans une boutique de développement. Zameer commence par définir précisément ce qu'est une limite de débit et par expliquer pourquoi elle est importante. Il présente ensuite l'algorithme de « leaky bucket » que Shopify utilise, et ses avantages pour les marchands comme pour les partenaires.

Avant de commencer : les outils dont vous aurez besoin

Tout d'abord, vous devrez disposer d'une boutique de développement. Ces boutiques sont gratuites avec un compte partenaire Shopify. Vous aurez aussi besoin d'une application privée sur la boutique de développement (nous verrons ensemble comment la configurer) et d'un éditeur de code. Nous utiliserons VS Code, mais vous pouvez choisir celui qui vous convient.

Si vous voulez suivre exactement le déroulé de la vidéo, sachez que nous utiliserons Ruby avec le framework Sinatra. Mais là aussi, vous pouvez choisir le langage de programmation que vous préférez.

À la fin de la série, nous aurons créé de bout en bout une application privée complète sur Shopify. Elle tentera d'effectuer des appels d'API, se verra opposer une limite de débit et gèrera cette limitation.

Si ce type de contenu vous intéresse, abonnez-vous à la chaîne YouTube ShopifyDevs et activez les notifications pour être informé dès qu'une nouvelle vidéo est disponible.

Définition d'une limite de débit API

Commençons par le commencement. Qu'est-ce qu'une limite de débit API ?

Pour cela, nous allons faire référence à la documentation de l’API Shopify.

Une limite de débit API est un moyen pour Shopify d'assurer la stabilité de la plateforme. Nous avons une offre API très souple, disponible à la fois sur REST, le standard web, et sur GraphQL, une option récente et novatrice. Sans limite de débit, tous les utilisateurs pourraient effectuer autant d'appels d'API qu'ils le souhaiteraient, à tout moment.

Au premier abord, cela peut sembler plutôt positif. Pourquoi voudriez-vous être limité de quelque manière que ce soit dans la gestion de vos données sur la plateforme Shopify ?

Le problème avec cette approche est qu'elle n'est pas viable à grande échelle. Si tous les développeurs pouvaient accéder à l'API Shopify et envoyer un nombre illimité de requêtes, les serveurs Shopify seraient soumis à une pression énorme. À terme, cela pourrait conduire à des temps d’arrêt du service.

Les temps d’arrêt peuvent affecter l'ensemble des serveurs, ce qui signifie que les marchands ne pourraient pas accéder à leurs boutiques et que vos applications ne fonctionneraient pas. Une limite de débit API est donc une manière pour nous de contrôler le nombre de requêtes que peut faire chaque application sur la plateforme. Elle nous permet de nous assurer que vous ne faites pas d'appels d’API superflus, et surtout que tous les appels d’API obtiennent bien une réponse.

Nos serveurs restent disponibles et les temps de réponse sont courts car, sur l'ensemble de la plateforme, nous sommes capables de maintenir un niveau de requêtes stable.

Les différents types de limites de débit

Tout d'abord, il est important de comprendre qu'il existe différents types de limites de débit.

La limite de débit la plus courante est probablement celle basée sur les requêtes, qui est utilisée par l'API administrateur REST. Une limite de débit basée sur les requêtes est liée au nombre de requêtes individuelles que vous effectuez.

Comparaison des limites de débit par API

Comme vous pouvez le voir dans le tableau comparatif des limites de débit par API ci-dessus, la première colonne indique la limite standard pour les forfaits Shopify classiques. Pour les marchands Shopify Plus, ces chiffres sont doublés pour chaque limite.

Dans la plupart des cas, nous ferons référence aux chiffres standard.

API administrateur REST : un système de limite de débit basé sur les requêtes

Avec l'API administrateur REST Shopify, vous avez droit à deux requêtes par seconde. Cette limite est très facile à suivre, vous pouvez facilement calculer combien de requêtes vous pouvez envoyer en une minute, une heure ou même une journée.

Avec cette approche, le type de requête que vous effectuez n'a pas d'importance. Quelle que soit la requête, qu'elle soit identique à une requête précédente ou qu'il s'agisse d'une mise à jour, d'une suppression ou d'une simple récupération de données, vous aurez toujours une limite de deux requêtes par seconde.

API administrateur GraphQL : un système de limite de débit basé sur les points

GraphQL utilise un niveau supérieur de limites de requêtes, avec ce que l'on appelle un coût de requête calculé. Cette approche vous permet toujours de lire et de mettre à jour des données en utilisant des requêtes et des mutations, mais au contraire de l'approche précédente, elle tient compte de la complexité de chacune des requêtes. Certaines actions telles que la mise à jour de données, par exemple, demandent plus de ressources que la simple récupération de données.

La limite de débit pour les requêtes GraphQL est ainsi définie selon un système de points. Un forfait standard vous accorde 50 points par seconde. Le système est très simple. Une requête coûte 10 points pour toute mutation qui entraîne la mise à jour, la création ou la suppression de données. La récupération de données, elle, ne coûte qu'un point.

GraphQL est assez intéressant. Nous n'entrerons pas dans tous les détails ici, mais il est possible d'imbriquer des données dans GraphQL.

Imaginons que vous voulez récupérer une commande, mais également toutes les rubriques au sein de cette commande. Cela ne vous coûtera pas seulement un point. Si votre commande a 10 rubriques, chacune d'entre elles vous coûtera un point, et la commande valant elle-même un point, le total pour cette requête sera donc de 11 points.

Voilà sommairement comment cela fonctionne. C'est assez simple à calculer vous-même en étudiant l'API GraphQL.

Dans la plupart des cas, GraphQL est plus efficace. Si vous ne savez pas quelle API choisir, nous vous recommandons GraphQL, pour cette raison et pour plusieurs autres raisons que nous expliquerons plus tard dans cette série.

API Storefront : un système de limite de débit temporel

Le dernier type de limite de débit API est la limite temporelle, comme celle utilisée pour l'API Storefront. Dans cette approche, ce n'est pas le nombre de requêtes qui est pris en compte, mais la durée écoulée entre chaque requête.

Nous l'utilisons principalement pour nos implémentations headless (sans interface graphique), donc nous n'allons pas approfondir le sujet, mais la différence est importante à comprendre.

L'algorithme du seau qui fuit, ou « leaky bucket »

Le second point important en matière de limites de débit sur Shopify concerne l'algorithme du seau qui fuit, ou « leaky bucket » en anglais.

Pour bien comprendre cet algorithme, imaginez-vous un seau qui contient un nombre prédéfini de billes. Le seau laisse s'écouler une bille par seconde, ce qui signifie que vous pouvez ajouter une autre bille au même rythme. Si votre seau est plein, vous ne pouvez plus ajouter de billes. Le nombre de billes que peut contenir votre seau dépend de différents facteurs.

Taille des seaux de l'API administrateur REST pour le forfait standard et pour Shopify Plus

Un forfait standard utilisant l'API administrateur REST a une taille de seau de 40 requêtes par application et par boutique.

Cela signifie que, si vous avez une application publique installée sur deux boutiques, il n'y a aucun lien ni aucune dépendance entre ces deux installations. Chacune d'entre elles a sa propre limite de débit. Dans le cas de l'API administrateur REST, un total de 40 requêtes leur est alloué. Vous pouvez donc faire 40 requêtes depuis votre application privée ou votre application publique.

Imaginons que nous souhaitions créer un produit. Comme nous l'avons déjà dit, l'approche est assez simple dans REST. Chaque requête compte comme une unité de votre limite de débit.

Nous créons donc un produit et nous lançons ainsi une bille dans le seau. Pour notre deuxième action, la mise à jour ou la suppression de données par exemple, nous lançons une autre bille dans le seau.

Vous voyez ainsi comment, au fil du temps, le seau va peu à peu se remplir. Vous ne pouvez effectuer une nouvelle requête que si vous avez encore de la place dans le seau pour y jeter une autre bille. Si le seau est plein et que vous essayez de lancer une bille, Shopify renverra une erreur 429 : « Trop de requêtes », « Vous avez atteint votre limite de débit », « Nous ne pouvons pas traiter votre requête. » Vous devrez alors attendre.

C'est là qu'intervient le concept de fuite.

Votre seau a donc la place pour 40 requêtes. Mais en parallèle, il évacue constamment des requêtes précédentes.

Qu'est-ce que cela veut dire ?

Cela signifie que, avec un taux de fuite de deux requêtes par seconde, votre seau retrouve chaque seconde la place pour deux billes, ou deux requêtes, de plus. Cela ne vaut que si votre seau n'est pas vide. S'il est vide car vous n'avez pas fait de requête dans l'heure écoulée, la taille du seau est toujours de 40. Vous ne pouvez pas aller au-delà.

Ce qui n'est pas dans le seau ne peut pas s'en écouler !

Par contre, si vous faites des requêtes, disons 10 requêtes en une seconde, vous ajoutez 10 billes dans votre seau qui peut en contenir 40. Une seconde plus tard, deux billes s'écoulent. Votre seau contient donc désormais 8 billes et a de la place pour 32 billes de plus, ou 32 requêtes.

Pourquoi cet algorithme du seau qui fuit ?

Nous avons choisi cette approche très simple pour vous permettre de faire un nombre élevé de requêtes en un temps très court. Avec une simple limite de débit de deux appels par seconde, cela n'aurait pas été possible.

Imaginons que votre application fonctionne de la manière suivante : à chaque commande qui arrive, vous mettez à jour tous les produits figurant dans la commande, et vous incrémentez une valeur enregistrée dans les tags des produits (pour suivre le nombre total de produits vendus par exemple).

Chaque commande aura un nombre X de mises à jour de produits.

Vous voyez rapidement que plus les commandes arrivent, plus le nombre de requêtes à effectuer augmente. Avec la méthode du seau qui fuit, et puisque la taille de votre seau est de 40, si une commande avec 20 rubriques arrive, vous pouvez faire 20 requêtes différentes pour chacun des produits en même temps.

Avec un taux de fuite de deux appels par seconde, vous aurez de la place dans votre seau : 20 billes entrent, et une seconde plus tard, deux en sortent, ce qui en laisse donc seulement 18 à l'intérieur. Vous comprenez ainsi comment cette possibilité de faire des requêtes en rafale vous offre, à vous et à votre application, un peu plus de souplesse.

C'est pourquoi nous avons choisi cette approche.

Pour GraphQL, la méthode est assez semblable. Vous avez également un seau, mais d'une taille différente.

Dans ce cas, le seau peut contenir 1 000 points. Et le taux de fuite est de 50 par seconde. Les différents objets et mutations ont des coûts différents.

Consultez la documentation pour connaître le coût de chaque mutation et de chaque requête.

Ces informations vous aideront à comprendre combien de requêtes vous pouvez effectuer sur une période de temps donnée avec GraphQL.

Ainsi se termine notre introduction aux limites de débit. Nous avons couvert les différentes méthodes disponibles, avec les différents types de requêtes, et expliqué l'importance de l'algorithme du seau qui fuit pour la stabilité de la plateforme.

L'algorithme du seau qui fuit : données supplémentaires

En ce qui concerne notre volume d'API, nous avons arbitrairement choisi une journée dans un jeu de données couvrant les 30 derniers jours.

Vous voyez ainsi le volume de requêtes API reçues en une journée sur 4 de nos points de terminaison REST les plus populaires.

Products reçoit 222 millions d'appels d'API uniques par jour, InventoryLevels 158 millions, Orders 137 millions et les champs méta 106 millions.

On peut dire que le volume de trafic sur les serveurs Shopify est assez considérable. Nous avons choisi d'imposer des limites de débit parce que c’était nécessaire pour offrir à nos marchands et à nos partenaires le plus haut niveau de stabilité et le meilleur temps de disponibilité.

Nous sommes reconnaissants aux développeurs de créer des applications qui respectent ces limites de débit. Dans le prochain article de cette série, nous aborderons plus en détail les bonnes pratiques en matière de limite de débit.

---

Publié par Maud Leuenberger. Maud est la rédactrice en chef du blog français de Shopify.

Texte original par Zameer Masjedee. Traduction par Solenn Marchand.