Codice ridondante inviato in pipe con Micro-front-end

10

La mia comprensione dei Micro-frontend è che il problema chiave che risolvono è aiutare le imprese a disporre di più team, a disparati gruppi, a lavorare su singoli componenti / piccole app che saranno utilizzate per comporre una grande applicazione web.

Qui il problema chiave da risolvere è la capacità di più team di lavorare in modo indipendente ed essere ancora in grado di costruire un grande composito. Il problema NON riguarda avere un pacchetto di rilascio snello per l'utente finale . Questa comprensione è corretta?

È vero che se utilizziamo più app piccole per comporre un'applicazione web di grandi dimensioni, potremmo potenzialmente avere più piccole app che inviano la stessa libreria Javascript ( come Lodash ) a i browser degli utenti finali come parte dei loro singoli bundle di fornitori che portano a una certa quantità di codice duplicato / ridondante inviato all'utente?

Non è una preoccupazione di cui dovremmo preoccuparci mentre progettiamo l'applicazione front-end?

    
posta Kiran 12.08.2018 - 16:45
fonte

1 risposta

11

Hai assolutamente ragione che qui c'è un compromesso: fai trading in alcuni aspetti dell'esperienza utente per ottenere una migliore esperienza di sviluppo (che a sua volta potrebbe migliorare l'esperienza dell'utente in modi diversi). Ne vale la pena? Dipende.

es. Penso che Spotify utilizzi questo approccio per suddividere la loro UI in componenti isolati ( fonte ). Ogni widget vive in un iframe e quindi può avere un proprio set di librerie, ecc. Hanno il vincolo organizzativo unico che il lavoro viene eseguito da squadre autonome (un team interfunzionale). Ciò rende più difficile concordare standard aziendali e successivamente modificare questi standard. Quindi per loro, i micro-frontend aiutano a preservare una certa flessibilità. Ma senza questo approccio, forse la loro app desktop sarebbe meno di un maiale della memoria.

Il caching HTTP non è di grande aiuto: ogni micro-frontend potrebbe usare diverse versioni di framework. Inoltre, il costo della duplicazione non è solo il trasferimento dei dati, ma i costi lato client della (ri) compilazione delle librerie e memorizzazione di strutture di dati duplicate.

Personalmente, ritengo che tali micro-front-end possano essere un'architettura valida, ma probabilmente sono sconsigliabili a meno che

  • sei un'organizzazione molto grande con team altamente autonomi che lavorano tutti sull'interfaccia utente e hanno bisogno di rilasci frequenti (ad esempio ogni giorno) e
  • il tuo budget di prestazioni UX ha spazio per questa duplicazione, oppure il tuo prodotto è così buono che UX non ha importanza. Nota che le prestazioni dovrebbero essere testate su dispositivi di fascia bassa, non sul tuo computer di sviluppo.

Se la tua organizzazione non è enorme o se i tuoi team sono un po 'più specializzati, potrebbe essere più facile per tutti i soggetti coinvolti (gestione, sviluppatori e, infine, utenti) avere un processo di compilazione e implementazione comune che eviti duplicazioni inutili. Per esempio. se hai solo 4 team che lavorano sull'interfaccia utente, probabilmente possono parlare tra loro per concordare un insieme comune di librerie e come integrare il loro lavoro in un'architettura coesa.

I micro-front-end sembrano essere una di queste cose che sono davvero fantastiche ma che non ne hai proprio bisogno finché non operi su una scala.

    
risposta data 12.08.2018 - 23:23
fonte

Leggi altre domande sui tag