[ARCHITECTURE] Création d'une version expressjs du backend
#201
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Notre trajectoire est de remplacer l'ORM de Nest par knex, pour simplifier. Donc, on commence par ajouter des migrations qui vont créer les tables existantes dans le cas d'un démarrage sur un environnement vierge.
Notre trajectoire est de remplacer l'ORM de Nest par knex, pour simplifier. Donc, on commence par ajouter des migrations qui vont créer les tables existantes dans le cas d'un démarrage sur un environnement vierge.
Inutile d'utiliser une matrice, car on n'a qu'une seule valeur dedans : la 18.
C'est la bonne façon de le faire chez Scalingo. On remplace les migrations "ORM" par les migrations `knex` qui sera la nouvelle couche d'accès aux données.
Cette séparation va faciliter l'écriture de tests dont on va avoir besoin pour se débarrasser de Nest.
L'objectif est de se débarrasser de Nest qui est bien trop envahissant et verbeux. On passe sur du express tout simple. On laisse pour l'instant la possibilité d'instancier l'implémentation Nest, pour que la PROD continue de fonctionner en Nest tant que l'implémentation express est incomplète.
La valeur 2 est une valeur legacy. Knex conseille, dans sa doc, d'utiliser 0. https://knexjs.org/guide/#pool
On remplace des fonctionnalités assurées par Nest.
On remplace des fonctionnalités assurées par Nest.
On remplace des fonctionnalités assurées par Nest.
… pour suivre la recommandation `WARN` reçue quand on exécute un `docker compose`
… pour le cas où une nouvelle instance de MonEspaceNIS2 est déployée.
... dans la version Express
… dans la partie Express.
...dans la partie Express. On reprend la philosophie d'avoir 3 fenêtres différentes de limites.
… pour respecter une bonne pratique de sécurité.
... car lors de notre phase de test, un problème de concurrence entre les tests se pose. Notre implémentation ne permettait pas d'avoir plusieurs instances d'Express en parallèle. Le `fetch` d'un test A tapait le serveur d'un test B. `Supertest` semble être fait pour gérer ce genre de problème.
ThibaudMZN
approved these changes
Oct 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Nous ne souhaitons plus utiliser
NestJScar c'est une complexité disproportionnée pour les quelques routes REST dont a besoin MonEspaceNIS2.Cette PR ajoute une version
expressjsdu backend, qui est activable grâce à une variable d'environnementCette version est iso-feature du Nest existant :
POST /informations-emailsPOST /simulateur-reponseexpressknexLe serveur existant est bougé dans
serveur.nest.ts.La nouvelle version est
serveur.express.ts.Une façade
serveur.tsfait l'aiguillage entre les 2.Au passage on permet d'instancier un serveur en lui injectant des dépendances, pour faciliter le testing.