Limitation des requêtes en JavaScript : comment ne pas faire tomber l'API

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Rate limiting et throttling en JavaScript : Protection et performance

\n\n

Avez-vous déjà réfléchi à la raison pour laquelle, après quelques dizaines de clics rapides sur le bouton « Envoyer », votre service préféré cesse soudainement de répondre ? Ou pourquoi certains sites vous demandent d'« attendre 30 secondes » avant de renvoyer un formulaire ? La réponse réside dans deux mécanismes puissants qui sauvent le backend de la surcharge et les utilisateurs des « bugs » : rate limiting et throttling.

\n\n

Dans cet article, nous allons voir comment appliquer ces techniques en JavaScript pur et Node.js. Vous découvrirez en quoi le throttle diffère du debounce, comment écrire un simple rate limiter pour une API et pourquoi votre site fonctionnera plus rapidement. C'est parti !

\n\n

Qu'est-ce que le rate limiting et pourquoi en a-t-on besoin ?

\n\n

Rate limiting (limitation du débit des requêtes) est un mécanisme de protection qui limite le nombre de requêtes d'un client (ou d'une adresse IP) sur une période donnée. Imaginez une barrière : une voiture peut passer, mais seulement une fois toutes les 10 secondes.

\n\n

Où cela s'applique-t-il ?

\n
    \n
  • Protection des API contre les attaques DDoS et le spam.
  • \n
  • Prévention de la surcharge du serveur lors de requêtes massives.
  • \n
  • Contrôle de l'utilisation des ressources dans les API payantes (par exemple, 100 requêtes par heure).
  • \n
  • Protection contre les erreurs de « boucle infinie » côté client.
  • \n
\n\n

Contrairement au throttling, qui lisse le flux de requêtes, le rate limiting est un mur rigide : « Stop, tu as dépassé la limite ».

\n\n

Throttling vs Debounce : la principale différence

\n\n

On confond souvent le throttling et le debounce. Mettons les points sur les « i ».

\n\n
    \n
  • Throttle — garantit qu'une fonction ne sera pas appelée plus d'une fois toutes les N millisecondes. Imaginez un robinet d'eau : vous l'ouvrez, et l'eau coule à un débit constant, même si vous secouez la poignée plus rapidement.
  • \n
  • Debounce — retarde l'appel d'une fonction jusqu'à ce que N millisecondes se soient écoulées depuis le dernier événement. Idéal pour la recherche avec autocomplétion : tant que l'utilisateur tape, la requête n'est pas envoyée.
  • \n
\n\n

Dans le contexte du rate limiting, c'est le throttle qui nous intéresse — nous voulons contrôler la fréquence, et non pas retarder les requêtes.

\n\n

Rate limiter simple en JavaScript

\n\n

Écrivons notre propre implémentation d'un rate limiter en Node.js. Il mémorisera l'heure de la dernière requête de chaque utilisateur et bloquera les appels trop fréquents.

\n\n
class RateLimiter {\n  constructor(limit, windowMs) {\n    this.limit = limit;          // Maximum de requêtes\n    this.windowMs = windowMs;    // Fenêtre de temps en ms\n    this.requests = new Map();   // Stockage : userId -> [timestamps]\n  }\n\n  allow(userId) {\n    const now = Date.now();\n    const userRequests = this.requests.get(userId) || [];\n    \n    // Suppression des entrées obsolètes\n    const recentRequests = userRequests.filter(\n      ts => now - ts < this.windowMs\n    );\n    \n    if (recentRequests.length >= this.limit) {\n      console.log(`Rate limit dépassé pour ${userId}`);\n      return false;\n    }\n    \n    recentRequests.push(now);\n    this.requests.set(userId, recentRequests);\n    return true;\n  }\n}\n\n// Utilisation\nconst limiter = new RateLimiter(5, 60000); // 5 requêtes par minute\n\n// Simulation de requêtes\nfor (let i = 0; i < 10; i++) {\n  setTimeout(() => {\n    const allowed = limiter.allow('user123');\n    console.log(`Requête ${i+1}: ${allowed ? '✅ Autorisée' : '❌ Bloquée'}`);\n  }, i * 2000); // Toutes les 2 secondes\n}
\n\n

Ce code est parfait à des fins éducatives, mais en production, il est préférable d'utiliser des solutions prêtes à l'emploi (par exemple, express-rate-limit pour Express ou rate-limiter-flexible).

\n\n

Throttling côté client : protection contre les clics rapides

\n\n

Le problème survient souvent côté client : l'utilisateur appuie plusieurs fois sur le bouton « Envoyer », et les requêtes partent en parallèle. R

Blogs

Book Recommendations