[FEATURE] Ajouter un endpoint pour créer une entrée dans la base de journalisation (PIX-8516)

[igorissen]

🦄 Problème

Le worker côté API écoutant les jobs pgboss de type “journalisation” doit pouvoir communiquer à l’application de journalisation une instruction de création d’une nouvelle entrée dans la base de journalisation.

🤖 Proposition

• Mettre en place l'API Rest avec Hapi
• Ajouter un endpoint pour créer une entrée dans la base de journalisation

🌈 Remarques

⚠️ Cette PR ne comprends pas l'implémentation de la partie Authentification pour la communication entre l'api Pix et l'api Pix Audit Logger. Ceci est à faire dans une autre PR.

L'implémentation de l'API diffère de celle sur Pix, notamment grâce à l'utilisation du Typescript, et chaque point reste à valider avec l'équipe.

Une liste non exhaustive des différences :

Vitest vs Jest

Le support de la partie ESM par Jest est encore expérimental comme décrit sur cette doc. Après un test de Jest sur le projet, nous nous sommes heurtés à une erreur décrit sur cette issue de ts-jestqui n'est pour le moment pas corrigé sans avoir à faire un workaround. Le fait que Vitest vienne avec un support natif de ESM et Typescript, donc sans configuration spécifique, nous a poussé à partir dessus.

Controller

• Le dossier application a été renommé en controller pour mieux refléter ce qu'il y a dedans (controllers + routes). En clean archi, le dossier application contient normalement les usecases comme sur ce schéma. Ce qui n'est pas le cas sur l'API Pix et cause une confusion sur l'architecture car elle mélange l'hexagonale et la clean archi. A voir pour garder le nommage.

• Sur l'API Pix, il y avait un fichier pour la/les routes du controller (ex: index.js) et un autre fichier pour le controller (ex: account-recovery-controller.js). C'est unifié sur cette PR dans un seul fichier create-audit-log.controller.ts. Le nom index.js n'est pas clair pour dire que c'est une route et non obligatoire en ESM.

• Un fichier controller par route afin d'améliorer la lisibilité. Cela évite d'avoir plusieurs endpoints dans un même fichier et donc d'avoir des centaines de lignes de code dessus.

• Un autre format de nommage qui ressemble à celui du usecase (action-sujet.controller.ts). Ceci aussi par clarté car cela permet, à la lecture du nom du fichier, de comprendre ce que fait le controller.

Models

• Nous privilégions pour les objets du domaines, les classes par rapport aux interfaces car les classes permettent, que ce soit dans le contructeur ou par des méthodes, d'implémenter de la logique métier dedans.
• Pour les types utilitaires, utilisés par l'agrégat/objet du domaine, on privilégie les types de fait de sa facilité à faire de
  la composition dessus.
• Les types utilitaires sont stockés dans un autre fichier models.definition.ts.

Repositories

Le nommage utilisé sur Pix API des repository (ex: AuthenticationMethodRepository) ne permet pas de savoir la source de donnée utilisée. Cela peut très bien être du Postgres, InMemory, Redis, d'une autre API...
De plus, l'implémentation est directement utilisé dans le usecase ce qui entraîne un couplage entre les 2 comme par exemple le passage d'une transaction du usecase vers le repository.

Typescript, nous permettant d'utiliser les interfaces, introduit une couche d'abstraction permettant d'éviter ce couplage.
En effet, les consommateurs du repository utiliseront, comme typage, l'interface plutôt que l'implémentation.

Dans notre cas, l'interface est AuditLogRepository et son implémentation AuditLogPostgresRepository. A noter que cela permet aussi la présence de la source de donnée utilisée dans le nom de l'implémentation grâce à la couche d'abstraction décrite plus haut 😄

💯 Pour tester

• Exécuter la commande npm ci (si ce n'est pas fait)
• Exécuter la commande npm run db:reset
• Si une erreur survient avec un message Database pix_audit_logging does not exist
  • Exécuter la commande npm run db:create
  • Exécuter la commande npm run db:migrate
• Exécuter la commande npm start

Cas en succès

• Faire un appel sur la route http://localhost:3001/api/audit-logs avec la méthode POST et le payload suivant

{
    "targetUserId": "2",
    "userId": "3",
    "action": "ANONYMIZATION",
    "occurredAt": "2023-07-03",
    "role": "SUPPORT",
    "client": "PIX_ADMIN"
}

• Vérifier que la réponse à un code HTTP 204 NO_CONTENT sans payload

Cas en erreur

• Faire un appel sur la route http://localhost:3001/api/audit-logs avec la méthode POST et le payload suivant

{
    "targetUserId": "2",
    "userId": "3",
    "action": "HELLO",
    "occurredAt": "2023-07-03",
    "role": "METIER",
    "client": "PIX_CONNECT"
}

• Vérifier que la réponse à un code HTTP 400 BAD_REQUEST et un payload contenant un message d'erreur

[reibecca]

 ✅ Testé fonctionnellement sur Postman

[clemlatz]

Testé fonctionnellement avec l'outil http de Webstorm ✅