Se moquer dun monorepo

(22 novembre 2020)

Ceci est une image réelle de notre environnement de développement après que nous ayons créé un serveur simulé pour notre dépôt

Avec nombre croissant de services étant créés sur notre backend, notre développement frontend a commencé à être affecté par le nombre de dépôts et de serveurs dont vous aviez besoin à installer localement pour démarrer le frontend. Et si nous prenons également en compte notre ( refonte de larchitecture du frontend ), nous savions que nous devions prendre des mesures pour avoir un expérience de développement rapide et fluide. Cest là quintervient notre serveur simulé monorepo.

Un peu sur LumApps

Si vous ne connaissez pas LumApps , nous sommes un société de technologie mondiale avec des équipes R & D en France qui fournit à nos clients un SaaS Digital Workplace solution, qui crée un espace de travail holistique, intégré à plusieurs suites et outils de collaboration. Vous voulez en savoir un peu plus sur nous? Rendez-vous sur LumApps.com et jetez un œil!

Ce dont nous avions besoin

Jusquà quelques années Il y a peu, notre application frontend était assez simple à lancer dans votre propre environnement de développement pour commencer à coder. Vous avez exécuté le frontend et le backend, et cest tout! Mais depuis que la société et lapplication ont connu une croissance exponentielle au cours des deux dernières années, avec nouveaux services créés et nouveaux développeurs venant pour se développer le produit, démarrer lapplication localement nétait pas aussi simple quauparavant.

Ces nouveaux services signifiaient que vous deviez les configurer sur votre machine, ce qui prenait non seulement du temps à installer, mais aussi un beaucoup de CPU, créant ainsi une combinaison vraiment difficile pour nos environnements de développement. Nous avions besoin dun système qui nous permette de:

  • Supprimer ces dépendances de services pour le développement local et avoir un serveur unique qui servait les données dont le frontend avait besoin pour le développement local, augmentant ainsi le temps de développement local 🚀
  • Créer un ensemble de données que toutes les équipes pourraient réutiliser afin de développer leurs fonctionnalités. Cela signifiait partager ces données entre les équipes et permettre à ces équipes de créer leurs propres ensembles de données afin de supprimer / ajouter une configuration pour chaque configuration déquipe spécifique 🛠
  • Avoir un ensemble cohérent de données qui peut être réutilisé pour Tests unitaires et dintégration ✅

Comment nous lavons fait

Après quelques recherches , nous avons trouvé un module npm astucieux appelé json-server qui nous a permis de créer une fausse API REST complète avec vraiment pas de configuration du tout. Cest vraiment un outil étonnant , car il permet non seulement de simuler des données et de créer un serveur, mais il fournit beaucoup de fonctionnalités principales de lAPI prêtes à lemploi, ce qui fait de cet outil le niveau suivant en matière de moquerie. Avec lui, nous pourrions par exemple exécuter un POST pour créer une ressource et la prochaine fois que nous ferons un GET pour récupérer la liste de ressources, la ressource récemment créée serait là! Cela vous permet également de créer express js middlewares qui peut être utilisé pour modifier requêtes et réponses, nous donnant un accès complet pour changer tout ce que nous voulons!

json-server

Obtenez une fausse API REST complète avec zéro codage en moins de 30 secondes

www.npmjs.com

En plus de cela, nous avons créé un petit fichier node js qui nous a permis de gérer facilement ces faux fichiers sur un monorepo.Fondamentalement, json-server a besoin dun point dentrée json où se trouvent les données factices, mais comme nous utilisons une architecture monorepo, nous voulions chaque paquet doit avoir ses propres données simulées afin quils soient les propriétaires de ces données et en plus, cela nous permet de voir clairement le points de terminaison consommés par un package. Ce fichier node js est un script exécuté avant json-server et il:

  • Parcourt chacun des packages de notre espace de travail et recherche les fichiers nommés api.json sur le _mocks et les combine tous dans un seul fichier avec toutes les données de chaque paquet. Il prend également en compte les autres configurations json-server , telles que routes ou middlewares , et les place tous ensemble dans un même emplacement
Un dossier utilisateur avec un sous-dossier appelé _mocks et 3 fichiers: api.json, routes.json et user.middleware.js
Voici à quoi ressemble notre package utilisateur avec ses propres simulations définies
  • Écrit dans un dossier prédéfini ces fichiers combinés et exécute json-server avec ces fichiers en entrée .
  • Tout cela est exécuté en une seule commande yarn mocks qui crée les fichiers puis lance json-server .
  • Nous avons également autorisé chaque module à créer différents scénarios pour leurs réponses API, que nous appelons remplacements . Chaque package peut créer autant de remplacements quil le souhaite, qui sont un sous-ensemble des données renvoyées par lAPI, avec des valeurs différentes remplacées et modifiées afin que lAPI renvoie un scénario différent. Par exemple, notre réponse API pour notre service de notifications ressemble à ceci:
Une réponse API pour notre service de notifications avec les éléments clés, les notifications non lues avec une valeur de 5 et plus en vrai
Notre service de notifications renvoie une liste de notifications à afficher, combien dentre elles nont pas été lues par lutilisateur et sil y a plus de notifications pour récupérer

Mais que se passerait-il si nous voulions lancer facilement un frontend où lutilisateur na pas du tout de notifications? Dans ce cas, nous créons le remplacement no-notifications.api.json qui remplace ce fichier:

Une réponse dAPI pour notre service de notifications avec les notifications non lues avec une valeur de 0 et plus en faux
Remplacer pour un scénario où il ny a pas de notifications pour lutilisateur actuel

Au niveau du dossier, notre package de notifications ressemble à ceci:

Nous avons beaucoup de scénarios différents pour notre centre de notifications 😅

Et pour appliquer ces remplacements, nous lançons simplement yarn mocks -override no-notifications et notre fichier node js chercheront les différents remplacements créés sur chaque package avec le nom no-notifications

et fusionnent en profondeur leurs valeurs avec les valeurs dorigine de chaque réponse dAPI. Cela signifie également que sil existe dautres packages qui souhaitent créer un remplacement pour le scénario no-notifications , ils peuvent également le faire ! Il leur suffit de créer un fichier appelé no-notifications.api.json dans leur _mocks dossier.

Enfin, vous pouvez également appliquer plusieurs remplacements à la fois en faisant yarn se moque -override no-notifications, admin, no-posts. Cela appliquera ces remplacements lun après lautre, en remplaçant chaque clé dans les réponses de lAPI dans lordre indiqué.

Et maintenant

Nous devons encore passer par quelques scénarios supplémentaires que nous voulons aborder pour permettre à nos développeurs davoir une expérience de développement plus fluide:

  • Créez automatiquement des simulations à partir dun service backend distant.
  • Validez périodiquement ces simulations contre un service backend distant afin de vérifier que la réponse de lAPI na pas change.
  • Ouvrez le script de ce petit nœud js pour ceux dentre vous qui utilisent monorepos et que vous souhaitez réutiliser ce code, vous pouvez le faire! Restez à laffût des développements futurs sur ce sujet!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *