Architettura di frontend su scala per grandi organizzazioni

(Daniel Ostapenko) ( 14 ottobre 2020)

Ciao! Voglio discutere con te come gestire larchitettura Frontend nelle grandi organizzazioni. Mi sembra che non ci siano molti articoli su questo argomento e non sia spiegato bene.

Per grande organizzazione in questo articolo, intendo le aziende, in cui il numero di ingegneri front-end inizia ad essere più grande di 15 e la società ha almeno più progetti di frontend.

Non voglio discutere di problemi di gestione o problemi di dominio aziendale, quelli che si vedono comunemente in aziende così grandi, ma concentriamoci solo sullarchitettura frontend invece.

Larchitettura frontend è coinvolta in troppe aree oggigiorno, quindi per cominciare proporrei di dividerla nelle seguenti sezioni:

Schema architettura frontend

1. Visual Code

Partiamo dallargomento più semplice, secondo me, è il codice visivo delle nostre applicazioni.

Molto probabilmente perché sviluppiamo più applicazioni di frontend presso la stessa azienda che le vogliamo avere:

  • riconoscimento del marchio
  • la stessa UI / UX

Per raggiungere questo obiettivo abbiamo bisogno di un sistema di progettazione. Il team di progettazione deve elaborare il sistema di progettazione e seguire tali linee guida di progettazione in tutti i progetti di prodotto futuri. Anche questo è già un compito molto complesso e richiede molte discussioni e allineamenti tra il team di progettazione, gli ingegneri e il prodotto.

Dal punto di vista del front-end, dobbiamo fornire uno strumento per implementare e condividere questo sistema di progettazione tra gli ingegneri. Una buona soluzione può essere la creazione del pacchetto npm, che sarà rappresentato visivamente da un Storybook o da uno strumento simile. A mio parere, è molto importante disporre di una risorsa Web dedicata (con URL) con documentazione su come utilizzare questo pacchetto. Questa risorsa Web verrà utilizzata dagli ingegneri front-end e dai designer e può essere un ottimo punto di riferimento in conversazioni tra di loro.

Visual Code

Riepilogo:

A questo punto abbiamo un sistema di progettazione e la sua rappresentazione in un pacchetto e la relativa documentazione interattiva. Condividiamo e adottiamo questo pacchetto in tutte le nostre applicazioni front-end.

2. Struttura del codice

Parliamo di un un po di ingegneria quotidiana. Implementiamo nuove funzionalità, correggiamo bug, refactoring del codice se necessario. Ci teniamo alla nostra base di codice, cercando di renderla piacevole e facilmente comprensibile. Ma cosa succede quando iniziamo ad avere non 1, non 2, ma dozzine di piccoli o grandi progetti in azienda? Di solito, le persone sono raggruppate attorno ad alcuni progetti e iniziano a lavorare solo con questo gruppo di progetti. Per la nostra natura umana e il tempo limitato, di solito, non possiamo occuparci di più di 2-3-5 progetti contemporaneamente. Quindi, naturalmente, iniziamo ad avere questi gruppi di influenze. Btw, grazie alla NASA per una foto così straordinaria per la mia analogia 😃

Gruppi di influenze

Ma iniziamo ad avere sempre più casi, quando le persone hanno -teams collaborazioni, hanno bisogno di controllare il codice e le soluzioni degli altri, correggere alcuni bug anche in altre applicazioni o aggiungere qualcosa di cui hanno bisogno allinterno di alcune app esterne (esterne per il loro gruppo di influenza). La cattiva notizia è che questo processo sta avvenendo nelle grandi aziende quasi incontrollato. La buona notizia: possiamo contribuire a migliorarla.

Come? Corretta. Fornendo la stessa struttura del codice , linee guida per la codifica e la strutturazione per tutti i progetti in azienda.

Approfondiamo cosa intendiamo per struttura del codice:

  • La struttura delle cartelle nel progetto
    Quando gli ingegneri entrano per la prima volta in un nuovo progetto, con la stessa struttura delle cartelle del loro progetto, dove sanno che tutto aiuta molto a navigare e cercare.
  • File di configurazione o di supporto
    File come package.json, .gitignore, .editorconfig, webpack.config, ecc. Dovrebbero essere sempre nello stesso posto, in ogni progetto, lo stesso è collegato ai file di configurazione dei test o ai file CI se necessari.
  • Posizione fissa dei tipi di file
    Se la posizione degli stessi tipi di file è la seguente sempre la stessa struttura funziona anche alla grande. Ad esempio, se la cartella del componente ha sempre un file style.css:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Struttura interna dei componenti
    La struttura allinterno dei file dovrebbe essere la stessa: ordine di importazioni, esportazioni, posizione della funzione pubblica , tipi e così via. In ogni tipo di file, dovresti sapere cosa aspettarti.
  • Convenzioni di denominazione
    Include i nomi di cartelle, file, variabili, funzioni, classi, tipi, ecc.
  • Convenzioni di codifica
    In generale, direi che le convenzioni di codifica sono una sezione molto ampia, ma qui voglio solo includere cose che non si adattano al resto delle sezioni, come ; o not ; 😁 e simili .

La stessa struttura del codice e il set di strumenti del progetto in pratica sono molto stretti e aiutatevi a vicenda a coesistere. Per set di strumenti intendo strumenti CLI (bootstrap del progetto, linting, test, ecc.), Estensioni IDE, ecc. Discuteremo largomento del set di strumenti nelle sezioni successive.

Struttura del codice

Riepilogo:

Dopo aver applicato questa sezione e averla adottata, dovremmo avere tutti i progetti in tutta lorganizzazione con la stessa struttura di cartelle, linee guida di denominazione, struttura di file, ecc. Ogni sviluppatore idealmente può saltare in qualsiasi altro progetto e non perdersi completamente lì. Questo “completamente perso” è anche molto connesso allo stack tecnologico utilizzato allinterno del progetto, quindi parliamone.

3. Tech Stack

Simile al precedente sezione, vogliamo avere uno stack tecnologico unificato in tutti i progetti dellorganizzazione. Il ragionamento per questo è molto simile: vogliamo che i nostri ingegneri si sentano a proprio agio con tutti i progetti in tutta lazienda.

Nei progetti Frontend, i componenti dello stack tecnologico possono essere: framework, basato su quel progetto è costruito, il linguaggio principale, processore di stili, livello dati (es. Apollo), gestione dello stato, test, linting del codice, sistema di compilazione e altro.

Ovviamente, in tutte le regole ci sono eccezioni. E in questo argomento, vorrei anche fare unosservazione, che a volte alcune tecnologie si adattano perfettamente ad alcuni progetti specifici, anche se quelle tecnologie non fanno parte dello stack tecnologico globale dellazienda. Tuttavia, ogni volta che questa idea viene ad allontanarsi dal com pany stack tecnologico dovresti pensarci due volte perché il costo di supportare queste cose è molto alto, quindi i vantaggi devono essere notevoli.

Citiamo qui uno stack tecnologico generico che può adattarsi alla maggior parte dei progetti ( ovviamente copre solo una parte del vero stack tecnologico, ma può essere un buon punto di partenza per qualcuno 🤷):

Stack

Dopo aver definito lo stack tecnologico nella nostra azienda e averlo concordato, ci sono anche altri pilastri molto importanti del successo .

Primo: dobbiamo annota lo stack tecnologico nel documento . Il documento, , che dovrebbe essere condiviso bene e facilmente tra gli ingegneri , in modo che possano sempre fornire un collegamento luno allaltro come prova.

Secondo: dovremmo di nuovo scrivere e condividere il documento con il modo come dovrebbero essere avviati i nuovi progetti e bootstrap, utilizzando lo stack tecnologico definito .

Tech Stack

Riepilogo:

Dopo aver implementato e adottato tutto ciò che abbiamo “menzionato sopra, dovresti avere tutti i tuoi progetti presso lorganizzazione per condividere lo stesso stack tecnologico. Idealmente, senza differenze. Non idealmente – con differenze insignificanti. Se aggiungiamo anche la sezione precedente, il codice, le cartelle, la struttura dei file dovrebbero essere quasi identico nei tuoi progetti.Quindi navigare in qualsiasi progetto dovrebbe essere un compito molto facile. Buono 😊

4. Strumenti

Questo argomento è molto importante. Ora utilizziamo alcuni strumenti aggiuntivi quasi ovunque: per creare lanugine, creare app, CI, generatori di componenti e molto altro ancora. Ecco perché vedo se possiamo scegliere gli strumenti corretti per i nostri progetti: è fondamentale. Buona attrezzatura vs cattiva attrezzatura (o nessuna attrezzatura), è lo stesso di un confronto tra automazione e test manuale .

Abbiamo appena parlato prima nelle sezioni precedenti dello stack tecnologico e della struttura del codice e abbiamo detto che dobbiamo scrivere molta documentazione per far sì che le persone li seguano. Ma il set di strumenti corretto può darti lopportunità di automatizzare seguendo le linee guida della tua azienda .

Per Ad esempio, se si dispone di uno stile di codifica specificato, è possibile fornire alle persone il set di strumenti di linting, che per impostazione predefinita segue quelle regole. Se disponi dello stack tecnologico definito, un buon strumento CLI ti darà lopportunità di avviare un nuovo progetto con quelle specifiche tecnologie dal tuo stack tecnologico.

Proviamo a discutere quali parti di larchitettura del frontend può essere coperta da strumenti:

  • Struttura e stile del codice
    Come abbiamo discusso in precedenza, questo può essere facilmente automatizzato dagli strumenti
  • Bootstrap del progetto
    Non lo fai ” Non è necessario creare una nuova struttura del progetto, installare manualmente tutti i pacchetti necessari, ecc.
  • Generazione di componenti
    La maggior parte delle volte alcuni componenti della tua applicazione non contengono nemmeno un singolo file, quindi la creazione di file, il collegamento / limportazione possono richiedere tempo, quindi questo può essere automatizzato.
  • Avvia e crea
    Ovviamente, la cosa più ovvia per lauto mate – come crei o avvii la tua applicazione.
  • Test
    Il processo di creazione del tuo app per i test e che esegue effettivamente tutti i tipi di test: unità, integrazione, ecc.
  • Gestione delle dipendenze
    Come sappiamo, circa l80\% del nostro codice ora è costituito da dipendenze. Quindi dobbiamo tenerli aggiornati e gestirli in una grande azienda non è una cosa facile.
  • Dipendenze tra progetti
    Molto probabilmente i nostri progetti non funzionano in modo isolato e potrebbero dipendere da altri progetti o essere una dipendenza per qualche altro progetto, quindi potremmo aver bisogno di alcuni strumenti per rendere più facile il processo di collegamento, sviluppo in una combinazione di più progetti (come Bit , ad esempio), ecc.
  • CI
    CI è una parte essenziale del nostro set di strumenti quotidiani e lautomazione e lunificazione di esso possono essere un lavoro molto vantaggioso per la tua organizzazione.

Se non vuoi sviluppare un nuovo set di strumenti personale, posso consigliare il set di strumenti NX , come uno dei candidati più interessanti. , sembra che i creatori di Babel abbiano adottato una soluzione simile, che potresti voler controllare – Roma . Questi strumenti non coprono tutto, ma gran parte di ciò di cui abbiamo parlato, quindi possono essere un buon punto di partenza.

Strumenti

Riepilogo:

Immagina quanto può diventare grande la nostra architettura dopo aver completato e adottato tutte le sezioni 🧙

Ogni progetto è lo stesso, mantenuto e gestito dal set di strumenti unificato. Ogni progetto può iniziare e costruire allo stesso modo. Nuovi componenti vengono generati nello stesso posto e con le stesse linee guida di denominazione.

Ma è così “dolce” o ha degli svantaggi? Come con qualsiasi soluzione, ha degli svantaggi. Uno di questi: ha bisogno di tempo per lonboarding di nuovi ingegneri nella tua azienda. Ma se tutto viene fatto in modo molto naturale (come le persone si sono abituate già in altri strumenti esistenti) e documentato, allora questo non diventa un grosso problema se lo si confronta con i vantaggi della velocità di sviluppo, unopportunità per gli ingegneri con cui lavorare qualsiasi base di codice facilmente, ecc.

5. Produzione

Di solito, riguardo a questa parte dellarchitettura del frontend, gli ingegneri si prendono cura di meno.Forse perché la maggior parte delle volte non è collegato alla codifica stessa🤷 e probabilmente non è così eccitante, ma non meno importante ☝️

Nella produzione di solito abbiamo bisogno di occuparci delle cose successive:

  • Analytics
    Tutti i tipi di diversi eventi di monitoraggio, ecc. Cose come Google Analytics , Segmento , HotJar , ecc.
  • Monitoraggio dello stato
    Ciò include cose, come i controlli dello stato, che possono essere anche test eseguiti in produzione, segnalazione di errori (come Sentry ), ecc.
  • Prestazioni
    È un po simile allelemento precedente, ma più orientato alle prestazioni. Ciò include la misurazione del tempo di risposta, la prima pittura significativa, ecc. (Probabilmente lo strumento n. 1 – Faro )
  • Test A / B
    Tutti i tipi di soluzioni di test A / B o flag di funzionalità.
  • Caching
    Strumenti come Varnish , Cloudflare .

Tutti possono essere unificati nelle tue applicazioni front-end dellazienda, semplificando la vita dei tuoi ingegneri . Ad esempio, aggiungendo pacchetti con le configurazioni iniziali predefinite e aggiungendo quei pacchetti al tuo progetto di bootstrap.

Un altro pezzo della produzione è la preparazione del codice, come:

  • Minificazione
    Solo minimizzazione del codice 😄
  • Mappatura sorgente
    Le mappe sorgente potrebbero essere necessarie anche per altri strumenti, come Sentry.
  • Preparazione delle risorse
    Preparazione per schermi con risoluzioni diverse, ritaglio di immagini, ecc.

Questi sono ottimi candidati da aggiungere a il set di strumenti che abbiamo per la gestione delle applicazioni front-end, di cui stavamo parlando nella sezione Strumenti.

Produzione

Riepilogo:

Idealmente, dovrebbero essere tutti aggiunto a ciascun progetto di frontend per impostazione predefinita nella fase di bootstrap. E gli ingegneri si occuperebbero solo di aggiungere chiavi API corrette nelle posizioni corrette per gli strumenti.

6. Sviluppo

Strumento CLI

In parte abbiamo già discusso lesperienza di sviluppo nella sezione Strumenti, quando abbiamo toccato lo strumento CLI frontend. Gli strumenti unificati sono una parte importante degli ingegneri “quotidianamente, ma non tutto.

API

Una comoda API con cui lavorare a livello locale è la seconda cosa fantastica che possiamo fare per migliorare lo sviluppatore esperienza e velocità di sviluppo. Di solito servire API localmente per ingegneri front-end non è un processo banale: questo potrebbe includere linstallazione di strumenti o framework, con i quali non possono avere familiarità. Anche se la configurazione dockerizzata può richiedere una quantità enorme di elaborazione risorse dalle macchine dello sviluppatore (se non lo è, può essere considerato come una configurazione). Quale può essere una soluzione in questo caso – API servita esterna. Può essere un singolo server per tutti gli ingegneri o un meccanismo per eseguire il bootstrap facilmente il tuo server dedicato per lo sviluppo.

CI

CI è la terza parte importante. Potrei presumere che la tua azienda abbia già scelto alcuni strumenti CI per il frontend e utilizzi questo strumento unico (ad es. Circle CI ,

Concourse CI o qualsiasi altro). In caso contrario, dovresti unificarlo.

La configurazione CI del particolare progetto, a mio parere, dovrebbe far parte del lavoro del team, che sta lavorando al progetto. Questo dà la possibilità a CI di essere stabile perché ci sono persone che sono interessate a CI a lavorare, usarlo ogni giorno e hanno il potere e le capacità per aggiustarlo, configurarlo e migliorarlo.

Tuttavia, non tutto il lavoro dovrebbe essere svolto dal team. Per le applicazioni front-end esiste un gruppo piuttosto specifico di lavori, che potenzialmente possono essere necessari. Soprattutto, se riuscissimo a unificare la struttura di cartelle / codice, stack tecnologico, ecc. Quindi, dopo un po di tempo nella tua azienda, potrebbe arrivare il momento in cui sarai in grado di rilevare quei modelli per le fasi del tuo strumento CI, implementare quelle fasi come una sorta di “elementi costitutivi” e offri ai tuoi ingegneri lopportunità di costruire le loro pipeline CI da questi “elementi costitutivi” unificati.

Ambienti demo

E infine lultima – verifica di la funzionalità implementata.Dopo che gli ingegneri hanno fatto e implementato tutto, hanno quasi sempre bisogno di controllare in qualche modo come appare e come funziona e condividerlo con altri ingegneri, progettisti o altre parti interessate. Per tali esigenze, funziona molto bene la versione temporanea distribuita dellapplicazione per il PR specifico con lURL fornito.

App temporaneamente distribuito
App distribuito temporaneamente

Questa soluzione accelera molto la comunicazione tra diversi team e persone e penso che sia solo un deve avere. Tuttavia, questa versione distribuita temporaneamente dovrebbe essere il più vicino possibile alla produzione, perché può anche essere un ottimo strumento per controllare alcuni errori superficiali o bug.

Questo può essere facilmente aggiunto ai tuoi progetti e automatizzato se il tuo frontend la creazione di applicazioni e le pipeline del processo di distribuzione sono unificate. Inoltre, strumenti simili o simili come Kubernetes e Helm possono aiutare molto nellimplementazione.

Sviluppo

Riepilogo:

Flussi di sviluppo comodi ed efficienti con un unico strumento CI con elementi costitutivi per realizzare qualsiasi Pipeline CI, con strumenti frontend CLI unificati e ambienti demo. Tutto ciò dovrebbe rendere il nostro processo di sviluppo il più agevole possibile. Moltiplicalo per il numero di ingegneri che hai in azienda e capirai quanto sia vantaggioso.

7. Modularità

Questo argomento è molto ampio e potrebbe richiedere un articolo separato per parlarne, ma proverei brevemente a esaminarlo.

Nelle grandi organizzazioni, le basi di codice enormi non sono rare cosa. Con tutti i problemi noti che si uniscono a loro, come pipeline CI lente, problemi con il lavoro collaborativo, test lenti, ecc. Quindi la grande parte dellarchitettura frontend è una decisione su quanto granulare vogliamo vedere applicazioni / moduli frontend indipendenti.

Ora abbiamo 3 modelli principali:

  • Monolith
    Un grande repository con un singolo progetto e tutto il codice lì, tutti i team stanno lavorando insieme in questo repository contemporaneamente.
  • Monorepo
    Molti progetti, ma ancora un grande repository ( monorepo nel wiki ). Tutti i team stanno ancora lavorando allo stesso repository, ma con progetti diversi. Esistono già opportunità per risolvere alcuni problemi, che abbiamo con un approccio monolite, eseguendo pipeline solo per progetti specifici, progetti hanno suite di test più piccole, ecc. Strumenti come Lerna può semplificarti la vita se scegli questo approccio.
  • Repo per progetto
    Ogni progetto ha il proprio repository e tutte le cose di supporto, come pipeline CI, distribuzioni, ecc.

In tutti questi modelli il progetto può significare unapplicazione di frontend indipendente, pagina, modulo di frontend indipendente, ecc. Dipende da quanto granulare vuoi decidere di dividere le tue applicazioni di front-end. Nella maggior parte dei casi, questa divisione dovrebbe essere sincronizzata con la struttura organizzativa e la gestione delle persone desiderate.

Il secondo grande argomento dopo aver deciso come dividere la tua applicazione sarà come collegare insieme questi pezzi (se hai deciso per dividere lapplicazione).

E qui abbiamo i prossimi approcci:

  • Composizione in fase di compilazione
    I tuoi progetti possono essere solo pacchetti npm, installati e composti durante il tempo di compilazione.
  • Server- composizione laterale
    Questo approccio di solito include il rendering lato server e la composizione che avviene su un server. Strumenti come Hypernova possono aiutare a organizzarlo meglio.
  • Composizione lato client
    Composizione dei progetti allinterno del browser. Nel blog di Martin Fowler, cè una spiegazione abbastanza buona di alcuni approcci – qui . Inoltre, è molto importante menzionare Module Federation , un nuovo approccio introdotto in Webpack 5 .
  • Composizione del percorso
    Super semplice: ogni progetto ha il proprio URL ea “livello Nginx” decidiamo dove reindirizzare gli utenti.(scusa, per una spiegazione del genere 😄 ma ho pensato che fosse la più facile da capire)

Come ho detto prima, è molto difficile trattare questo argomento in un formato così piccolo, ma spero che tu abbia almeno trovato alcune idee interessanti per te stesso e approfondirai gli argomenti da solo 🙏🏻 .

Modularità

Riepilogo:

Abbiamo trovato un modo per rendere i nostri team felici e produttivi organizzando i repository, suddividendo i nostri progetti in parti più piccole (molto probabilmente), rendendo i team più indipendenti luno dallaltro.

Benvenuto in paradiso 😁

8. Test

Ci sono così tante risorse disponibili sul test per applicazioni front-end, quindi proverei a non entrare nei dettagli, cosa che puoi fare easi trovo, ma concentrati maggiormente sui problemi delle grandi organizzazioni e su come possiamo risolverli.

Il primo – ogni ingegnere comprende le tecniche di test in modo diverso, anche quale tecnica applicare in quale situazione, come scrivere ” buoni “test, ecc. Quindi ha molto senso documentare in modo abbastanza preciso tutte le sfumature e le linee guida dei livelli di test utilizzati in azienda e le linee guida per ciascuno di essi.

Possibili livelli di test che si desidera avere nella tua strategia di test:

  • Test unitari
  • Test di integrazione
  • Test E2E
  • … e altri

Inoltre, come secondo passaggio, dobbiamo unificarli tra le diverse applicazioni di frontend dellazienda, in modo che le persone non abbiano domande su come e cosa testare quando vengono trasferite a un progetto diverso.

Se sei riuscito a unificare i livelli e gli approcci di test, puoi automaticamente aiutare a risolvere il secondo problema: testare la configurazione dellinfrastruttura. Ogni progetto da solo necessita di impostarlo e configurarlo localmente e su CI di alcune infrastrutture di test. Ad esempio, abbiamo deciso di utilizzare Cypress e deve essere eseguito allinterno di unimmagine finestra mobile. Questo richiede un po di tempo per essere impostato localmente e su CI. Se lo moltiplichiamo per il numero di progetti che abbiamo – è unenorme quantità di tempo. Quindi, la soluzione – per unificarlo di nuovo e fornire alcuni strumenti per i progetti. Sembra facile, ma richiede molto tempo per limplementazione.

Test del tempo non di sviluppo

Volevo anche toccare un altro modo di testare le tue applicazioni dopo le funzionalità già implementate e distribuite. E sì, il monitoraggio ovviamente ne fa parte 😁.

Abbiamo già menzionato nelle sezioni precedenti il ​​monitoraggio degli errori e delle prestazioni per le applicazioni frontend, il monitoraggio del tempo di attività, la risposta da posizioni diverse.

È anche fantastico avere Lighthouse vengono eseguiti test sul tuo sito web (possono essere inclusi nelle pipeline CI). Per trovare più facili colli di bottiglia delle prestazioni, problemi di accessibilità e migliorare la qualità delle pagine web in generale.

E il last – test di produzione sui flussi aziendali più importanti, molto probabilmente funzioneranno meglio se eseguiti direttamente sui prodotti sullambiente, ma può anche essere possibile una modifica quando siamo in grado di eseguire tali test su un ambiente di staging / test, che è molto vicino a quello di produzione o addirittura lo rispecchia. Cè un articolo molto carino su questo argomento – (qui).

Test

Riepilogo:

Abbiamo chiare linee guida di test con livelli di test necessari definiti per ciascuna applicazione frontend. Abbiamo una singola pipeline CI per ogni applicazione e abbiamo un unico strumento CLI, che aiuta a eseguire test localmente.

Parola finale

Spero davvero che voi ragazzi abbiate trovato qualcosa di interessante in questo articolo. Mi dispiace molto, che nella maggior parte degli argomenti ho appena scalfito la superficie dei problemi. E saremo lieti di discuterne di più, quindi per favore lascia le tue domande nei commenti o inviami un ping direttamente su Twitter – @denieler .