Mocking a monorepo (Italiano)

(22 novembre 2020)

Questa è unimmagine reale del nostro ambiente di sviluppo dopo aver creato un server fittizio per il nostro repository

Con un crescente quantità di servizi creato sul nostro backend, lo sviluppo del nostro frontend ha iniziato a essere influenzato dal numero di repository e server necessari da installare localmente per avviare il frontend. E se prendiamo in considerazione anche la nostra ( rielaborazione dellarchitettura del frontend ), sapevamo che dovevamo agire per avere un esperienza di sviluppo veloce e fluida. È qui che entra in gioco il nostro server fittizio monorepo.

Qualcosa su LumApps

Se non conosci LumApps , siamo azienda tecnologica globale con team R & D in Francia che fornisce ai nostri clienti un SaaS Digital Workplace , che crea uno spazio di lavoro olistico, integrato con diverse suite e strumenti di collaborazione. Vuoi saperne di più su di noi? Vai su LumApps.com e dai unocchiata!

Di cosa avevamo bisogno

Fino a un paio danni fa, la nostra applicazione di frontend era abbastanza semplice da avviare nel proprio ambiente di sviluppo per iniziare a scrivere codice. Hai eseguito il frontend e il backend, e basta! Tuttavia, poiché lazienda e lapplicazione sono cresciute in modo esponenziale negli ultimi due anni, con nuovi servizi creati e nuovi sviluppatori in arrivo per sviluppare il prodotto, avviare lapplicazione localmente non è stato così facile come una volta.

Questi nuovi servizi significavano che avresti dovuto configurarli nella tua macchina, cosa che non solo richiedeva tempo per linstallazione, ma anche molta CPU, creando così una combinazione molto difficile per i nostri ambienti di sviluppo. Avevamo bisogno di un sistema che ci consentisse di:

  • Rimuovere le dipendenze dei servizi per lo sviluppo locale e disporre di un server singolo che fornisse i dati necessari al frontend per lo sviluppo locale e, di conseguenza, aumentando il tempo di sviluppo locale 🚀
  • Crea un insieme di dati che tutti i team possano riutilizzare per sviluppare le loro funzionalità. Ciò significava condividere i dati tra i team e consentire a tali team di creare i propri set di dati al fine di rimuovere / aggiungere la configurazione per ciascuno configurazione specifica del team 🛠
  • Avere un insieme coerente di dati che può essere riutilizzato per unit e test di integrazione ✅

Come abbiamo fatto

Dopo alcune ricerche , abbiamo trovato un elegante modulo npm chiamato json-server che ci ha permesso di creare una falsa API REST con davvero nessuna configurazione. È davvero uno strumento straordinario , poiché non solo consente di simulare dati e creare un server, ma fornisce molti funzionalità API di base fuori dagli schemi, il che rende questo strumento davvero il livello successivo quando si tratta di derisione. Con esso, potremmo ad esempio eseguire un POST per creare una risorsa e la prossima volta che faremo un GET per recuperare lelenco di risorse, la risorsa creata di recente sarebbe lì! Ci consente inoltre di creare middleware express js che può essere utilizzato per modificare richieste e risposte, dandoci pieno accesso per modificare ciò che vogliamo!

json-server

Ottieni unAPI REST falsa completa con zero codifica in meno di 30 secondi

www.npmjs.com

Inoltre, abbiamo creato un piccolo file js del nodo che ci ha permesso di gestire facilmente questi mock file su un monorepo.Fondamentalmente json-server necessita di un punto di ingresso json dove risiedono i dati fittizi, ma poiché stiamo utilizzando unarchitettura monorepo, abbiamo voluto ogni pacchetto deve avere i propri dati fittizi in modo che siano i proprietari di tali dati e inoltre ci consente di vedere chiaramente il endpoint consumati da un pacchetto. Questo file js del nodo è uno script eseguito prima di json-server e:

  • Passa attraverso ciascuno dei pacchetti nel nostro spazio di lavoro e cerca i file denominati api.json su _mocks e li combina tutti in un unico file con tutti i dati di ogni pacchetto. Prende in considerazione anche le altre configurazioni di json-server , come instrada o middleware e li inserisce tutti insieme in ununica posizione
Una cartella utente con una sottocartella denominata _mocks e 3 file: api.json, route.json e user.middleware.js
Questo è laspetto del nostro pacchetto utente con i suoi mock definiti
  • Scrive in una cartella predefinita quei file combinati ed esegue json-server con quei file come input .
  • Tutto questo viene eseguito in un unico comando filato deride che crea i file e quindi avvia json-server .
  • Abbiamo inoltre consentito a ciascun modulo di creare scenari diversi per le risposte API, che chiamiamo override . Ogni pacchetto può creare tutte le sostituzioni che desidera, che sono un sottoinsieme dei dati restituiti dallAPI, con valori diversi sovrascritti e modificati in modo che lAPI restituisca uno scenario diverso. Ad esempio, la nostra risposta API per il nostro servizio di notifiche è simile a questa:
Una risposta API per il nostro servizio di notifiche con gli elementi chiavi, notifiche non lette con valore 5 e più in true
Il nostro servizio di notifiche restituisce un elenco di notifiche da visualizzare, quante non sono state lette dallutente e se ci sono più notifiche per recuperare

Ma cosa succede se volessimo avviare facilmente un frontend in cui lutente non ha alcuna notifica? In tal caso creiamo loverride no-notification.api.json che sovrascrive questo file:

Una risposta API per il nostro servizio di notifiche con le notifiche non lette con valore 0 e altro in false
Esegui loverride per uno scenario in cui non sono presenti notifiche per lutente corrente

A livello di cartella, il nostro pacchetto di notifiche ha il seguente aspetto:

Abbiamo molti scenari diversi per il nostro centro notifiche 😅

E per applicare queste sostituzioni, lanciamo semplicemente filato mocks -override no-notification e il nostro file node js cercherà le diverse sostituzioni create su ciascun pacchetto con il nome no-notification

e uniscono in profondità i loro valori con i valori originali di ciascuna risposta API. Ciò significava anche che se ci sono altri pacchetti che desiderano creare un override per lo scenario senza notifiche possono farlo anche loro ! Devono solo creare un file chiamato no-notification.api.json nel loro _mocks cartella.

Infine, puoi anche applicare più sostituzioni contemporaneamente eseguendo filato prende in giro -override no-notifiche, admin, no-posts. Questo applicherà tali sostituzioni una dopo laltra, sovrascrivendo ciascuna chiave nelle risposte API nellordine fornito.

Cosa cè dopo

Dobbiamo ancora esaminare un altro paio di scenari che vogliamo affrontare per consentire ai nostri sviluppatori di avere unesperienza di sviluppo più fluida:

  • Crea automaticamente mock da un servizio di backend remoto.
  • Convalida periodicamente questi mock con un servizio di backend remoto per verificare che la risposta dellAPI non abbia funzionato cambiare.
  • Apri questo piccolo nodo js script così quelli di voi là fuori che usano monorepos e vuoi riutilizzare questo codice puoi farlo! Restate sintonizzati per futuri sviluppi su questo argomento!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *