Workers

Workers

Un worker est un service sans port ni domaine : un process de fond qui consomme une file d'attente, exécute des tâches planifiées ou traite des données en continu.

Quand choisir un worker

• Consommer une file (BullMQ, RabbitMQ, ou une simple liste Redis).
• Tâches récurrentes (envoi d'e-mails, synchronisation, nettoyage).
• Traitement long qui ne doit pas bloquer votre application web (génération de PDF, imports).

Créer un worker

1. + Nouveau service → type Worker.
2. Connectez le dépôt (ou l'image Docker) contenant le code.
3. Définissez si besoin une commande de démarrage dédiée. C'est pratique quand le worker vit dans le même dépôt que l'application web :

node dist/worker.js

Exemple : consommer une file Redis

import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL!);

while (true) {
  // BRPOP bloque jusqu'à ce qu'un job arrive
  const [, payload] = await redis.brpop("jobs:emails", 0);
  await sendEmail(JSON.parse(payload));
}

Le service web pousse les jobs (LPUSH jobs:emails …), le worker les dépile : les deux services partagent la même instance Redis du projet, connectée via ses variables d'environnement.

Bonnes pratiques

• Un worker = une responsabilité. Deux files très différentes méritent deux workers : chacun se scale et redémarre indépendamment.
• Gérez l'arrêt proprement : à la réception de SIGTERM, terminez le job en cours avant de quitter. Les redéploiements remplacent le process.
• Idempotence : un job peut être retraité après un redémarrage. Assurez-vous qu'un traitement double soit sans effet.

Les logs et métriques (CPU/mémoire) du worker sont disponibles comme pour n'importe quel service dans les onglets Logs et Observabilité.