De la théorie à la pratique de l’event sourcing : implémenter un service de remote config avec NestJS

Introduction

Lors d’une présentation de Ji-hyeok Won sur l’event sourcing au meetup serveur de Danggeun, cela m’a beaucoup aidé à mieux comprendre ce concept. J’ai résumé les notions de base de l’event sourcing et, à partir du contenu de cette présentation, j’ai créé un petit service de config basé sur NestJS, TypeScript et MongoDB.

• Original : Créer une plateforme interne évolutive avec l’event sourcing | Danggeun SERVER Meetup #2
• Exemple de code source du service de config en event sourcing

Concepts de base de l’event sourcing

• Contrairement à l’approche CRUD classique, tous les changements d’état sont enregistrés sous forme d’événements immuables, ce qui facilite l’audit et le rollback
• Comme un grand livre comptable, toutes les transactions (événements) sont enregistrées séquentiellement, ce qui permet de reconstruire à tout moment l’état actuel

Composants clés

• Événement
  • Inclut un ID unique, l’heure de création, le type d’événement, les informations utilisateur et le contenu (body), tout en garantissant l’immuabilité et l’autonomie de l’événement
• État
  • État final obtenu en rejouant tous les événements (avec possibilité d’utiliser des snapshots ou un cache si nécessaire)
• Reducer
  • Fonction pure qui reçoit l’état précédent et un événement, puis calcule un nouvel état tout en préservant l’immuabilité
• Entité
  • Regroupe les événements liés pour les gérer comme un seul objet, afin de consulter efficacement l’historique des modifications d’une entité donnée

Exemple d’implémentation et structure

• Configuration de base de l’environnement : démarrage de l’application avec NestJS
• Définition des entités et des événements
  • Utilisation d’interfaces TypeScript et de schémas MongoDB pour définir clairement différents événements (par ex. création de configuration, ajout/suppression de paramètres) ainsi que les objets d’état
• Implémentation du reducer :
  • Écriture de fonctions pures qui mettent à jour l’état selon le type d’événement, afin de calculer l’état final en rejouant la séquence d’événements
• Endpoints API et couche de service
  • Implémentation d’une API REST offrant la création, la consultation, l’ajout et la suppression de paramètres de config
  • Utilisation du pattern dispatch-commit pour traiter séquentiellement la publication des événements, le calcul de l’état et la persistance des événements

Améliorations supplémentaires et intégration avec des systèmes externes

• Interfaces génériques
  • Conception d’un repository d’événements réutilisable pour réduire la duplication de code et garantir la sûreté de typage
• Event handlers
  • Intégration avec des systèmes externes comme Slack pour effectuer des traitements supplémentaires, par exemple l’envoi de notifications lors de la survenue d’un événement
• Stratégies d’optimisation des performances
  • Snapshots : enregistrer l’état à un instant donné puis n’appliquer que les événements suivants afin de réduire le coût du rejeu complet
  • Caching : utiliser un cache en mémoire ou Redis pour fournir rapidement l’état d’entités fréquemment consultées

Conclusion

• L’event sourcing est une architecture puissante qui renforce la fiabilité et la maintenabilité en enregistrant clairement tout l’historique des changements
• Il convient de l’adopter progressivement selon le domaine, en l’accompagnant de stratégies d’optimisation comme les snapshots et le caching pour garantir les performances du système, tout en tenant compte de la courbe d’apprentissage

[guseod24]

Très bien ! ^0^