Retour au blog
Webhook vs Polling : Pourquoi JunkMail a choisi le temps réel (et pourquoi vous devriez aussi)

Webhook vs Polling : Pourquoi JunkMail a choisi le temps réel (et pourquoi vous devriez aussi)

Découvrez l'architecture technique derrière JunkMail. Comment nous gérons des milliers d'emails par seconde sans jamais faire attendre vos scripts de test.

Par L'équipe Engineering07/01/2026

Dans le monde du développement, il y a une promesse qui est souvent brisée : le "temps réel".

Combien de fois avez-vous codé un script qui doit attendre un événement extérieur (comme l'arrivée d'un email), pour finir par écrire une boucle while(true) qui bombarde une API toutes les deux secondes ? C'est ce qu'on appelle le Polling. Et en 2026, c'est un peu comme si vous alliez vérifier votre boîte aux lettres physique toutes les 5 minutes pour voir si le facteur est passé.

Chez JunkMail, nous avons construit notre infrastructure sur le principe inverse : le Webhook.

Plongeons sous le capot pour comprendre pourquoi ce choix change tout pour vos tests et vos applications.

Le Polling : Le gaspillage silencieux

Le Polling, c'est la méthode "bourrine". Votre application demande à JunkMail : "Est-ce que j'ai un mail ? Non. Et maintenant ? Non. Et là ? Toujours pas."

Pourquoi c'est une mauvaise idée :

  1. Gaspillage de ressources : Chaque requête consomme de la bande passante, du CPU sur votre serveur et sur le nôtre.
  2. Latence artificielle : Si vous interrogez toutes les 10 secondes, vous pouvez recevoir l'email avec 9,9 secondes de retard. Dans une pipeline CI/CD de 500 tests, ce retard devient inacceptable.
  3. Coût : Les API limitent souvent le nombre de requêtes par minute (Rate Limiting). Le polling vous fait atteindre ces limites très (trop) vite.

Le Webhook : "Ne nous appelez pas, on vous appelle"

Le Webhook, c'est l'approche élégante. Vous donnez une URL à JunkMail (votre endpoint), et nous restons silencieux. Dès qu'un email arrive et passe nos filtres, nous "poussons" la donnée vers vous instantanément.

Les avantages sont massifs :

  • Réactivité instantanée : Dès que le serveur SMTP Haraka termine de recevoir le mail, il est chez vous en quelques millisecondes.
  • Efficience : Une seule requête HTTP uniquement quand c'est nécessaire.
  • Évolutivité : Votre serveur peut gérer des milliers d'emails entrants sans avoir à maintenir des boucles d'attente complexes.

L'Architecture JunkMail : Une symphonie en quatre temps

Pour rendre ce temps réel possible, JunkMail utilise une stack technologique optimisée pour la performance pure.

1. La Réception (Haraka SMTP)

Nous utilisons Haraka, un serveur SMTP ultra-rapide écrit en Node.js. Contrairement aux serveurs traditionnels (Postfix, Exim), Haraka est piloté par des événements. Il nous permet d'intercepter l'email pendant qu'il arrive et de déclencher nos scripts immédiatement.

2. Le Cerveau (NestJS & Redis)

Une fois le mail reçu, il est envoyé à notre API NestJS. Le contenu est stocké de manière éphémère dans Redis, une base de données en mémoire. Pourquoi Redis ? Parce qu'écrire sur un disque dur est trop lent pour nos standards.

3. La Notification (Webhooks & WebSockets)

C'est ici que la magie opère.

  • Pour vos tests : Si vous avez configuré un Webhook, notre système envoie une requête POST vers votre URL avec le contenu JSON du mail.
  • Pour votre Dashboard : Nous utilisons les WebSockets (Socket.io). C'est ce qui fait que votre interface JunkMail clignote et affiche l'email sans que vous ayez besoin de rafraîchir la page.

4. Le Nettoyage (Cron & TTL)

La donnée est vivante, mais elle doit mourir. Nous utilisons les mécanismes de TTL (Time To Live) de Redis et des tâches programmées (Cron) pour garantir que vos emails disparaissent réellement après 24h ou 30 jours, selon votre plan.


Cas d'usage : Pourquoi les devs adorent nos Webhooks

Imaginons que vous testiez un flux de paiement qui envoie une facture.

Sans Webhook : Votre test Playwright doit boucler, gérer les timeouts, et potentiellement rater l'email si le réseau flanche. Votre code est rempli de sleep(5000).

Avec Webhook JunkMail : Votre test lance un petit serveur HTTP temporaire (via une bibliothèque comme express ou msw). Il configure l'URL du webhook sur JunkMail. Il attend simplement la requête POST. Dès qu'elle arrive, le test continue. Résultat : Vos tests sont 5x plus rapides et 100% stables.

Conclusion

L'architecture de JunkMail n'a pas été conçue pour simplement "stocker des mails". Elle a été pensée comme une infrastructure de données en temps réel.

En choisissant les Webhooks plutôt que le Polling, nous vous offrons l'outil le plus précis du marché pour vos automatisations. Parce qu'on sait que votre temps est la ressource la plus précieuse de votre stack.

Prêt à passer à la vitesse supérieure ? Configurez votre premier Webhook sur JunkMail Business.