Mocking a monorepo

(22. nov 2020)

Dette er et faktisk billede af vores udviklingsmiljø, efter at vi oprettede en mock-server til vores repo

Med en stigende mængde tjenester oprettes på vores backend, vores frontend-udvikling begyndte at blive påvirket af hvor mange repos og servere du havde brug for at installere lokalt for at få frontend i gang. Og hvis vi også tager vores ( frontend arkitektur omarbejde ) i betragtning, vidste vi, at vi var nødt til at tage handling for at have en hurtig og jævn udviklingsoplevelse. Det er her vores monorepo-mock-server kommer ind.

En lille smule om LumApps

Hvis du ikke ved om LumApps , er vi en globalt teknologisk firma med R & D-teams i Frankrig, der giver vores kunder et SaaS Digital Workplace løsning, der skaber et helhedsorienteret arbejdsområde, integreret med flere suiter og samarbejdsværktøjer. Vil du vide lidt mere om os? Gå over til LumApps.com og kig et kig!

Hvad vi havde brug for

Op til et par år siden var vores frontend-ansøgning ret ligetil at starte i dit eget udviklingsmiljø for at starte kodning. Du udførte frontend og backend, og det var det! Men da firmaet og applikationen er vokset eksponentielt i løbet af de sidste par år med nye tjenester oprettet og nye udviklere, der kommer ind for at udvikle produktet, var det ikke så let at starte programmet lokalt, som det plejede at være.

Disse nye tjenester betød, at du bliver nødt til at konfigurere dem på din maskine, hvilket ikke kun tog tid at opsætte, men også en meget CPU, hvilket skaber en virkelig hård kombination til vores udviklingsmiljøer. Vi havde brug for et system, der tillod os at:

  • Fjern disse afhængigheder af tjenester til lokal udvikling og har en enkelt server , der serverede de data, som frontend havde brug for til lokal udvikling, og dermed øget lokal udviklingstid 🚀
  • Opret et sæt data, som alle hold kunne genbruge for at udvikle deres funktionalitet. Dette betød at dele disse data på tværs af hold og lade disse teams oprette deres egne datasæt for at fjerne / tilføje konfiguration for hver specifik teamkonfiguration 🛠
  • Har et konsekvent sæt data , der kan genbruges til test af enhed og integration ✅

Hvordan vi gjorde det

Efter lidt research , vi fandt et nifty npm-modul kaldet json-server der tillod os at oprette en fuld falsk REST API egentlig ingen konfiguration overhovedet. Det er virkelig et fantastisk værktøj , da det ikke kun tillader at spotte data og oprette en server, men det giver en masse centrale API-funktionaliteter ud af kassen, hvilket gør dette værktøj til det næste niveau når det kommer til mocking. Med det kunne vi for eksempel udføre en POST for at oprette en ressource og næste gang vi laver en GET for at hente listen af ressourcer, den nyligt oprettede ressource ville være der! Det giver også mulighed for at oprette express js mellemprodukter , der kan bruges til at finjustere anmodninger og svar, hvilket giver os fuld adgang til at ændre hvad vi vil!

json-server

Få en fuld falsk REST API med nulkodning på mindre end 30 sekunder

www.npmjs.com

Oven i det oprettede vi en lille node js-fil, der gjorde det let for os at administrere disse mock filer på en monorepo.Dybest set json-server har brug for et json-indgangspunkt, hvor de mock-data lever, men da vi bruger en monorepo-arkitektur, ville vi gerne hver pakke har deres egne mock-data så de er ejerne af disse data, og det giver os desuden mulighed for tydeligt at se slutpunkter, som en pakke bruger. Denne node js-fil er et script, der udføres før json-server og det:

  • Går gennem hver af pakkerne i vores arbejdsområde og søger efter filer med navnet api.json _mocks -mappen og kombinerer dem alle i en enkelt fil med alle data fra hver pakke. Det tager også hensyn til de andre json-server konfigurationer, såsom ruter eller mellemprodukter alt sammen på en enkelt placering
En brugermappe med en undermappe kaldet _mocks og 3 filer: api.json, routes.json og user.middleware.js
Sådan ser vores brugerpakke ud med sine egne definerede mocks
  • Skriver til en foruddefineret mappe de kombinerede filer og udfører json-server med disse filer som input .
  • Dette udføres alt sammen i en enkelt kommando garn mocks opretter filerne og starter derefter json-server .
  • Vi tillod også, at hvert modul opretter forskellige scenarier for deres API-svar, som vi kalder tilsidesætter . Hver pakke kan oprette så mange tilsidesættelser, som de vil, som er en delmængde af de data, som APIen returnerer, med forskellige værdier tilsidesat og ændret, så APIen returnerer et andet scenario. Så for eksempel ser vores API-svar på vores meddelelsestjeneste sådan ud:
Et API-svar til vores meddelelsestjeneste med nøgleelementerne, ulæste meddelelser med en værdi på 5 og mere i ægte
Vores meddelelsestjeneste returnerer en liste over meddelelser, der skal vises, hvor mange af dem der ikke blev læst af brugeren, og hvis der er flere underretninger at hente

Men hvad hvis vi let ville starte en frontend, hvor brugeren slet ikke har nogen meddelelser? I så fald opretter vi tilsidesættelsen no-notifications.api.json , der tilsidesætter denne fil:

Et API-svar til vores meddelelsestjeneste med ulæste meddelelser med værdien 0 og mere i falsk
Tilsidesættelse af et scenarie, hvor der ikke er nogen meddelelser for den aktuelle bruger

På mappeniveau ser vores meddelelsespakke sådan ud:

Vi har mange forskellige scenarier for vores underretningscenter 😅

Og for at anvende disse tilsidesættelser lancerer vi bare garn mocks-override no-notifications og vores node js-fil vil se efter de forskellige tilsidesættelser, der oprettes på hver pakke med navnet no-notifications

og fusionerer dybt deres værdier med de originale værdier for hvert API-svar. Dette betød også, at hvis der er andre pakker, der ønsker at oprette en tilsidesættelse af no-notifications scenariet, kan de også gøre det ! De skal bare oprette en fil med navnet no-notifications.api.json i deres _mocks -mappe.

Endelig kan du også anvende flere tilsidesættelser på én gang ved at gøre garn mocks -override no-notifications, admin, no-posts. Dette gælder disse tilsidesættelser efter hinanden og tilsidesætter hver nøgle i API-svarene i den angivne rækkefølge.

Hvad er næste

Vi er stadig nødt til at gennemgå et par flere scenarier, som vi vil tackle for at give vores udviklere mulighed for at få en mere flydende udviklingsoplevelse:

  • Opret automatisk mocks fra en ekstern backend-tjeneste.
  • Validér periodisk disse mocks mod en ekstern backend-tjeneste for at kontrollere, at API-svaret ikke ændre.
  • Åbn kildekode denne lille node js script så de af jer derude, der bruger monorepos og ønsker at genbruge denne kode kan gøre det! Hold øje med den fremtidige udvikling inden for dette emne!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *