smile-nestjs-sqs - conçu pour utiliser SQS avec NestJS de façon plus sûre en production

Bonjour.
J’ai développé des services avec la combinaison NestJS + SQS en utilisant d’autres packages SQS de l’écosystème NestJS.
J’avais cependant rencontré plusieurs difficultés réelles en production. J’ai bien soumis une PR à certains packages, mais certains ne sont plus mis à jour, et d’autres ne considèrent même pas cela comme un problème. J’ai donc créé ce module pour résoudre ces points moi-même. En pratique, j’ai remplacé le module SQS que j’utilisais auparavant par celui-ci, et je l’utilise désormais de manière stable.
Je le partage en espérant qu’il sera utile à celles et ceux qui cherchent un module SQS pour NestJS, ou qui se posaient des questions similaires aux miennes.

Ce package présente les caractéristiques suivantes :

Compatible avec l’approche NestJS

Dans NestJS, il est possible de générer et d’importer dynamiquement des modules, puis d’injecter des handlers décorés pour une implémentation simple.
La signature est similaire à celle de la plupart des autres packages SQS.

@Module({  
  imports: [  
    ConfigModule.forRoot(),  
    SqsModule.registerAsync({  
      inject: [ConfigService],  
      useFactory: (config: ConfigService) => {  
        const region = config.getOrThrow<string>('AWS_REGION');  
        const queueUrl = config.getOrThrow<string>('ORDERS_QUEUE_URL');  
        const defaultSqsClient = new SQSClient({ region });  
  
        return {  
          defaultSqsClient,  
          consumers: [{ name: 'orders', queueUrl }],  
          producers: [{ name: 'orders', queueUrl }],  
        };  
      },  
    }),  
  ],  
})  
export class AppModule {}  
  
@Injectable()  
export class OrderQueueHandler {  
  @SqsMessageHandler('orders')  
  public async onMessage(message: Message): Promise<Message> {  
    // return message to ack/delete  
    return message;  
  }  
  
  @SqsConsumerEventHandler('orders', 'processing_error')  
  public onProcessingError(error: Error, message: Message) {  
    // report error  
  }  
}  

Utilisation des dernières versions des packages de la BBC

Ce package s’appuie sur les dernières versions des deux bibliothèques ci-dessous, qui dépassent 1,3 million de téléchargements hebdomadaires et sont les bibliothèques SQS les plus connues dans l’écosystème Node.js.

https://github.com/bbc/sqs-producer
https://github.com/bbc/sqs-consumer

sqs-consumer introduit un breaking change significatif à partir de la v14.
https://github.com/bbc/sqs-consumer/discussions/584

Jusqu’à la version 13 incluse, même si le handler SQS retournait void, cela était considéré comme un comportement d’ack.
À partir de la version 14, en revanche, c’est explicitement le message renvoyé par le handler SQS qui est considéré comme l’ack.
Ce changement est important : il est plus explicite, plus prévisible, et évite de semer la confusion chez les utilisateurs au moment d’implémenter l’ack.
Pourtant, la plupart des packages npm présentés aujourd’hui comme des modules NestJS SQS utilisent encore sqs-consumer en version 13 ou inférieure.

Validation au démarrage

Les mauvaises configurations sont détectées immédiatement au lancement de l’application, ce qui permet une utilisation plus sûre.

• Détection des noms de consumer/producer en doublon
• Erreur immédiate si un décorateur est utilisé sur un consumer inexistant
• Détection des fautes de frappe dans les noms d’événements
• Détection des incompatibilités de types de paramètres entre handlers batch/single
• Détection des incompatibilités de types de valeur de retour entre batch/single

Graceful shutdown

bbc/sqs-consumer fournit l’option pollingCompleteWaitTimeMs pour le graceful shutdown.
Et NestJS dispose de son propre cycle de vie.
À l’étape onModuleDestroy de NestJS, l’arrêt attend en interne que chaque consumer émette l’événement stopped.
Comme cet événement n’est émis qu’une fois le traitement du message en cours terminé, le traitement se termine correctement et le processus s’arrête en toute sécurité.
Comme cela est automatiquement relié au cycle de vie de NestJS,
si vous activez app.enableShutdownHooks(),
et que vous configurez correctement pollingCompleteWaitTimeMs et shutdownTimeoutMs, l’utilisation sera plus sûre même en cas d’arrêt brutal dans un environnement k8s.

En utilisant SQS en production, j’avais souvent l’impression d’attendre des mises à jour qui ne venaient jamais.
Cela créait des difficultés pour mettre en place une culture de développement robuste, et ce module est le résultat de cette démarche pour résoudre le problème.
Si vous travaillez dans un environnement similaire et vous posez des questions proches, je vous serais reconnaissant de l’essayer et de me faire part de vos retours.