Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Individuazione dei servizi
Il modello di scoperta del frontend migliora l'esperienza di sviluppo durante lo sviluppo, il test e la fornitura di microfrontend. Il pattern utilizza una configurazione condivisibile che descrive il punto di ingresso dei micro-frontend. La configurazione condivisibile include anche metadati aggiuntivi che vengono utilizzati per implementazioni sicure in ogni ambiente utilizzando versioni canarie.
Lo sviluppo frontend moderno prevede l'utilizzo di un'ampia varietà di strumenti e librerie per supportare la modularità durante lo sviluppo. Tradizionalmente, questo processo consisteva nel raggruppare il codice in singoli file che potevano essere ospitati in un CDN con l'obiettivo di ridurre al minimo le chiamate di rete durante l'esecuzione, incluso il caricamento iniziale (quando un'app si apre in un browser) e l'utilizzo (quando un cliente esegue azioni come la scelta di pulsanti o l'inserimento di informazioni).
Suddivisione dei pacchetti
Le architetture Micro-frontend risolvono i problemi di prestazioni causati da pacchetti molto grandi generati raggruppando singolarmente un ampio set di funzionalità. Ad esempio, un sito di e-commerce di grandi dimensioni può essere raggruppato in un file da 6 MB. JavaScript Nonostante la compressione, la dimensione del file potrebbe influire negativamente sull'esperienza dell'utente durante il caricamento dell'app e il download del file da un CDN ottimizzato per i dispositivi periferici.
Se dividi l'app in home page, dettagli del prodotto e micro-frontend del carrello, puoi utilizzare un meccanismo di raggruppamento per creare tre pacchetti singoli da 2 MB. Questa modifica potrebbe migliorare le prestazioni al primo caricamento del 300% quando gli utenti utilizzano la home page. I pacchetti di micro-frontend relativi al prodotto o al carrello vengono caricati in modo asincrono solo se e quando l'utente visita la pagina del prodotto di un articolo e decide di acquistarlo.
Sono disponibili molti framework e librerie basati su questo approccio, con vantaggi sia per i clienti che per gli sviluppatori. Per identificare i limiti aziendali che possono comportare il disaccoppiamento delle dipendenze nel codice, è possibile mappare diverse funzioni aziendali a più team. La proprietà distribuita introduce indipendenza e agilità.
Quando si dividono i pacchetti di build, è possibile utilizzare una configurazione per mappare i micro-frontend e gestire l'orchestrazione per il caricamento iniziale e per la navigazione dopo il caricamento. Quindi, la configurazione può essere utilizzata durante il runtime anziché durante la fase di compilazione. Ad esempio, il codice frontend lato client o il codice backend lato server possono effettuare una chiamata di rete iniziale a un'API per recuperare dinamicamente l'elenco dei micro-frontend. Recupera anche i metadati necessari per la composizione e l'integrazione. È possibile configurare strategie di failover e memorizzazione nella cache per garantire affidabilità e prestazioni. La mappatura dei microfrontend aiuta a rendere le implementazioni individuali di microfrontend individuabili dai microfrontend precedentemente distribuiti e orchestrati da un'app shell.
Versioni di Canary
Una versione canaria è un modello consolidato e popolare per l'implementazione di microservizi. Le release di Canary raggruppano gli utenti destinatari di una versione in più gruppi e rilasciano le modifiche gradualmente anziché sostituirle immediatamente (nota anche come distribuzione blu/verde). Un esempio di strategia di rilascio di Canary consiste nell'applicare una nuova modifica al 10% degli utenti target e aggiungerne il 10% ogni minuto, con una durata totale di 10 minuti per raggiungere il 100%.
L'obiettivo di una release Canary è ottenere un feedback tempestivo sulle modifiche, monitorando il sistema per ridurre l'impatto di eventuali problemi. Quando l'automazione è in atto, le metriche aziendali o di sistema possono essere monitorate da un sistema interno che può interrompere l'implementazione o avviare un rollback.
Ad esempio, una modifica potrebbe introdurre un bug che, nei primi due minuti di una versione, comporta una perdita di ricavi o un peggioramento delle prestazioni. Il monitoraggio automatico può avviare un allarme. Grazie al Service Discovery Pattern, l'allarme può interrompere l'implementazione e ripristinarlo immediatamente, interessando solo il 20 percento degli utenti anziché il 100 percento. L'azienda trae vantaggio dalla portata ridotta del problema.
Per un esempio di architettura che utilizza DynamoDB come storage per implementare un'API di amministrazione REST, consulta la soluzione Frontend Service Discovery on AWS su
