Découvrez BullMQ, une MessageQueue simple avec NodeJS

Imaginez une application web qui doit un exporter un zip, puis l’envoyer par e-mail, pour qu’un utilisateur puisse télécharger des données.

Si votre serveur attend que le zip soit compressé puis envoyé avant de répondre à l’utilisateur :

• la requête devient lente
• votre serveur peut bloquer
• la requête peut échouer à cause d’un timeout

La solution consiste à déléguer ce travail à un système de tâches asynchrones.

Au lieu de créer le zip directement, l’application ajoute une tâche dans une file :

(1) Exporter données (user@example.com) -- En cours...
(2) Exporter données (user2@test.com)   -- En attente
(3) Exporter données (user3@fake.com)   -- Tâche ajoutée

L’utilisateur, lui, va recevoir une confirmation immédiate du traitement de sa demande, et un autre processus (parfois un autre serveur, conteneur,…) se chargera de traiter la demande et d’envoyer l’email.

Comme ceci :

Lire la tâche en cours
|
Récupérer les données
|
Créer l'archive zip
|
Envoyer l'email (user@example.com)
|
Valider la tâche

Tant qu’il y a des tâches en cours, le processus les traitera les unes à la suite des autres, dans l’ordre d’arrivée (First In - First Out ou FIFO)

De cette manière, notre serveur web n’est pas bloqué par des tâches longues ou coûteuses, il peut continuer à traiter le reste de ses requêtes facilement !

Qu’est-ce que BullMQ ?

BullMQ est une bibliothèque permettant de gérer ce type de file de tâches.

Elle repose sur Redis, une base de données en mémoire très rapide qui sert à stocker et coordonner les tâches.

Si vous ne connaissez pas Redis, on vous a préparé un article dédié !

Le fonctionnement repose sur trois éléments :

• La queue (file) : l’endroit où les tâches sont ajoutées
• Les workers : des processus qui exécutent les tâches
• Redis : le moteur qui stocke les jobs et leur état

Le flux ressemble généralement à ceci :

1. L’application ajoute une tâche dans la queue
2. Redis stocke cette tâche
3. Un worker récupère la tâche
4. Le worker exécute l’action (ex : envoyer un email)

Ce modèle permet de séparer la logique métier principale des traitements lourds.

Attention, BullMQ n’est pas un MessageBroker, c’est simplement une file d’attente ! On va voir la différence un peu plus loin avec RabbitMQ par exemple.

Un exemple simple

Voici un exemple minimal avec Node.js pour ajouter une tâche dans une queue :

import { Queue } from "bullmq";

const emailQueue = new Queue("email-queue", {
  connection: {
    host: "localhost",
    port: 6379
  }
});

await emailQueue.add("send-welcome-email", {
  email: "user@example.com",
  name: "Alice"
});

Ce code ajoute une tâche appelée send-welcome-email dans Redis.

Et voici un exemple d’un Worker qui traite les tâches :

import { Worker } from "bullmq";

const worker = new Worker(
  "email-queue",
  async job => {
    const { email, name } = job.data;

    console.log(`Envoi de l'email de bienvenue à ${name} (${email})`);

    // Ici on pourrait appeler un service SMTP
    // sendEmail(email, ...)
  },
  {
    connection: {
      host: "localhost",
      port: 6379
    }
  }
);

Dès qu’une tâche est ajoutée, le worker la récupère et exécute le traitement.

Cas d’usage typiques

Les files de tâches comme BullMQ sont utilisées pour :

• envoyer des emails
• générer des rapports ou documents
• traiter des images ou vidéos
• importer de grandes quantités de données
• exécuter des tâches planifiées
• lancer des traitements lourds en arrière-plan

Dès qu’une opération peut prendre du temps ou échouer temporairement, une queue devient utile.

Les forces et faiblesses de BullMQ

BullMQ présente plusieurs avantages importants : il est performant, gèrent les “retries” en cas d’échecs, mais possède surtout une très bonne DX et n’a besoin que d’une dépendance d’infrastructure (Une base Redis).

Mais cela reste néanmoins une solution relativement simple, avec ses limites : limité à NodeJS, Python et PHP, il est également mois adapté aux architectures très distribuées.

Et RabbitMQ alors ?

La différence principale entre BullMQ et RabbitMQ est leur rôle :

• BullMQ est une bibliothèque de gestion de tâches.
• RabbitMQ est un message broker, conçu pour faire communiquer plusieurs services entre eux.

Avec RabbitMQ, chaque service peut envoyer des messages sur la Queue, et chaque service est libre de traiter un message comme il l’entend. BullMQ permet simplement d’envoyer une tâche de manière unilatérale, et avec une seule source de vérité (même si autant de Worker peuvent écouter les tâches).

RabbitMQ est aussi plus lourd à mettre en place, avec une infrastructure dédiée, et son protocol basé sur AMQP.

Note supplémentaire

Il est important de rappeler que BullMQ est capable de garder les tâches en mémoire à long terme, uniquement si la persistence est activée sur votre base de données Redis !