Nous avons décidé d'avoir une architecture de code structurée en séparant les différentes couches de notre API afin que cela soit plus facilement maintenable lors de futurs évolutions. De ce fait, dans le dossier nous avons ainsi plusieurs parties distinctes :

• controller : est appelé par 'routes' et va vérifié que les paramètres donnés sont corrects. Cette couche va ensuite appeler le repository (nous n'avons pas de couche intermédiaire car nous n'avons pas juger cela nécessaire au vu de la complexité des algorithmes utilisés).
• entity : correspond aux éléments utilisés lors des interactions avec la bases de données. Ces éléments et en particulier les types qui y sont utilisés seront détaillés dans une section particulière.
• logger : sert à afficher sur la sortie standard de l'application des informations sur les requêtes, les flux ... Et cela grâce à BsWinston.
• rabbit_receiver : contient la partie RabbitMQ et va écouter la file QNewCourse. Lorsque un élément est inséré dans la file par un autre service, celui va être récupéré et sauvegardé en base de données (via la couche 'repository').
• repository : est le dernier maillon de notre modèle. C'est ici que vont être insérés, modifiés ou récupérés les différents éléments qu'utilise l'application dans la base de données.
• routes : va contenir toutes les routes qui peuvent être utilisées sur l'API. D'ici on va appeler la couche 'controller'.

Pour développer cette application, nous avons créer plusieurs types et modules afin de couvrir tous nos besoins.

1. Concernant les messages nous avons créer trois types différents en fonction de l'état du message.

• Le premier sert lorsque le front crée un message. En effet, comme il n'est pas nécessaire de fournir tous les champs lors de l'insertion de données (certains sont auto-générés et d'autres sont calculés), on utilise ce type avec les champs nécessaires.
• Le second sert lors de la récupération des messages dans la base de données puisqu'il y a tous les champs dont le front à besoin à l'affichage.
• A cause de la complexité de la requête SQL pour récupérer les messages d'un cours, nous avons dû la faire manuellement. Cependant, cela implique que son résultat ne soit pas automatiquement traité par la dépendance Knex. Afin de pouvoir récupérer les différents messages contenus dans la réponse, nous avons dû créer un troisième type de message. Ce dernier permet de parser la réponse SQL et d'extraire la liste des messages qui seront ensuite transformés dans le format qui sera envoyé au front grâce au type précédant.

2. Le seconde type est celui qui permet de prendre en charge les likes. Contrairement au message, il n'y a pas de déclinaison en différents types puisqu'il y a autant de champs utilisés pour l'insertion et la suppression des likes.

3. Le dernier type est celui des channels. Sur le même modèle que celui des likes, il ne se décline qu'en un seul type puisqu'il n'y pas presque pas de différence entre l'insertion qui provient de la file RabbitMQ et la récupération utilisé par le front.

Dans le cahier des charges initial, il nous a été demandé de satisfaire six stories. L'intégralité des besoins pouvant être pris en charge par la Back ont été réalisé (l'affichage des messages en temps réel n'étant pas de notre ressort).

Concernant les règles de gestions, il y en a eu deux :

• Lors de la création de nouveau cours par le service concerné, nous recevons bien ce cours et l'ajoutons correctement en base. Cependant cette fonctionnalité n'est pas utilisé à ce jour car le groupe responsable de l'ensemble du front (parent au composant Forum) passe par le service de gestion des cours pour les récupérer. En faisant ainsi, ils viennent utiliser la route sécuriser de l'API du service de gestion des cours et vérifier que la personne qui fait la requête est bien connectée. De ce fait, nous n'avons pas implanté de vérification de token JWT sur cette route mais cela est une évolution faisable dans les prochaines versions si le client le souhaite.
• Nous avons choisi d'identifier l'auteur du message par son pseudo. Grâce à cela, l'utilisateur peut facilement interagir avec ses propres messages afin de les supprimer. De plus, chaque appel pour récupérer les messages demande de fournir l'utilisateur connecté. Cela a pour but de pouvoir identifier si cette personne a liké chacun des messages retournés ou non.