Codice ridondante inviato lungo il tubo con micro-frontend

La mia comprensione dei micro-frontend è che il problema chiave che risolvono è nell'aiutare le aziende a disporre di più, possibili team diversi, a lavorare su singoli componenti / piccole app che verranno utilizzate per comporre un'applicazione Web di grandi dimensioni.

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 la disponibilità di un bundle di versione snella per l'utente finale . Questa comprensione è corretta?

È vero che se utilizziamo più piccole app per comporre un'applicazione Web di grandi dimensioni, potremmo potenzialmente avere più piccole app che inviano la stessa libreria Javascript ( come Lodash ) ai browser degli utenti finali come parte del 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 durante la progettazione dell'applicazione front-end?

Hai assolutamente ragione sul fatto che ci sia un compromesso qui: stai commerciando in alcuni aspetti dell'esperienza dell'utente per ottenere una migliore esperienza per gli sviluppatori (che a sua volta potrebbe migliorare l'esperienza dell'utente in diversi modi). Ne vale la pena? Dipende.

Ad esempio, penso che Spotify utilizzi questo approccio per suddividere l'interfaccia utente in componenti isolati ( sorgente ). 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 a livello aziendale e successivamente modificarli. Quindi, per loro, i micro-frontend aiutano a preservare una certa flessibilità. Ma senza questo approccio, forse la loro app desktop sarebbe un po 'meno memoria.

La memorizzazione nella cache HTTP non sarà di grande aiuto: ogni micro-frontend potrebbe utilizzare versioni di framework diverse . Inoltre, il costo della duplicazione non è solo il trasferimento dei dati, ma i costi sul lato client della (ri) compilazione delle librerie e della memorizzazione delle strutture di dati duplicati.

Personalmente, penso che tali micro-frontend 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 devono effettuare rilasci molto frequenti (ad es. ogni giorno) e
• il budget per le prestazioni della tua UX ha spazio per questa duplicazione o il tuo prodotto è così buono che la UX non ha importanza. Si noti che le prestazioni devono essere testate su dispositivi di fascia bassa, non sulla macchina 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, in definitiva, utenti) avere un processo comune di compilazione e distribuzione che eviti inutili duplicazioni. Ad 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 coerente.

I micro-frontend sembrano essere una di queste cose davvero interessanti ma di cui non hai bisogno fino a quando non operi su larga scala.