Microservizi Frontend: Service Discovery e Strategie di Comunicazione

L'architettura a microservizi ha rivoluzionato lo sviluppo backend, consentendo ai team di creare servizi scalabili, resilienti e distribuibili in modo indipendente. Ora, questo modello architetturale viene sempre più adottato nel frontend, dando origine ai microservizi frontend, noti anche come micro frontends. Questo articolo approfondisce gli aspetti cruciali del service discovery e della comunicazione all'interno di un'architettura a microservizi frontend.

Cosa sono i Microservizi Frontend?

I microservizi frontend (o micro frontends) sono un approccio architetturale in cui un'applicazione frontend viene scomposta in unità più piccole, distribuibili e manutenibili in modo indipendente. Ogni micro frontend è in genere di proprietà di un team separato, consentendo una maggiore autonomia, cicli di sviluppo più rapidi e una scalabilità più semplice. A differenza dei frontend monolitici, in cui tutte le funzionalità sono strettamente accoppiate, i micro frontends promuovono la modularità e l'accoppiamento debole.

Vantaggi dei Microservizi Frontend:

• Distribuzione Indipendente: I team possono distribuire i propri micro frontends senza influire su altre parti dell'applicazione, riducendo i rischi di distribuzione e consentendo iterazioni più rapide.
• Diversità Tecnologica: Ogni team può scegliere lo stack tecnologico migliore per il proprio micro frontend specifico, consentendo la sperimentazione e l'innovazione.
• Scalabilità Migliorata: I micro frontends possono essere scalati indipendentemente in base alle loro esigenze specifiche, ottimizzando l'utilizzo delle risorse.
• Maggiore Autonomia del Team: I team hanno la piena proprietà dei propri micro frontends, il che porta a una maggiore autonomia e a un processo decisionale più rapido.
• Manutenzione Più Semplice: Le codebase più piccole sono più facili da mantenere e comprendere, riducendo il rischio di introdurre bug.

Sfide dei Microservizi Frontend:

• Maggiore Complessità: La gestione di più micro frontends può essere più complessa della gestione di un singolo frontend monolitico.
• Service Discovery e Comunicazione: L'implementazione di meccanismi efficaci di service discovery e comunicazione è fondamentale per il successo di un'architettura a micro frontend.
• Componenti Condivisi: La gestione di componenti e dipendenze condivisi tra i micro frontends può essere impegnativa.
• Ottimizzazione delle Prestazioni: L'ottimizzazione delle prestazioni tra più micro frontends richiede un'attenta considerazione delle strategie di caricamento e dei meccanismi di trasferimento dei dati.
• Test di Integrazione: I test di integrazione possono essere più complessi in un'architettura a micro frontend, poiché richiedono il test dell'interazione tra più unità indipendenti.

Service Discovery nei Microservizi Frontend

Il service discovery è il processo di localizzazione e connessione automatica ai servizi in un sistema distribuito. In un'architettura a microservizi frontend, il service discovery è essenziale per consentire ai micro frontends di comunicare tra loro e con i servizi backend. Esistono diversi approcci al service discovery nei microservizi frontend, ognuno con i propri vantaggi e svantaggi.

Approcci al Service Discovery:

1. Configurazione Statica:

In questo approccio, la posizione di ogni micro frontend è hardcoded in un file di configurazione o in una variabile d'ambiente. Questo è l'approccio più semplice, ma è anche il meno flessibile. Se la posizione di un micro frontend cambia, è necessario aggiornare il file di configurazione e ridistribuire l'applicazione.

Esempio:

            const microFrontendConfig = {
  "productCatalog": "https://product-catalog.example.com",
  "shoppingCart": "https://shopping-cart.example.com",
  "userProfile": "https://user-profile.example.com"
};

            

              
                Copy
              
            
          

Pro:

• Semplice da implementare.

Contro:

• Non scalabile.
• Richiede la ridistribuzione per le modifiche alla configurazione.
• Non resiliente ai guasti.

2. Service Discovery Basato su DNS:

Questo approccio utilizza il DNS per risolvere la posizione dei micro frontends. A ogni micro frontend viene assegnato un record DNS e i client possono utilizzare le query DNS per scoprire la sua posizione. Questo approccio è più flessibile della configurazione statica, poiché è possibile aggiornare i record DNS senza ridistribuire l'applicazione.

Esempio:

Supponendo di avere record DNS configurati come questo:

• product-catalog.microfrontends.example.com IN A 192.0.2.10
• shopping-cart.microfrontends.example.com IN A 192.0.2.11

Il codice del tuo frontend potrebbe apparire così:

            const microFrontendUrls = {
  "productCatalog": `http://${new URL("product-catalog.microfrontends.example.com").hostname}`,
  "shoppingCart": `http://${new URL("shopping-cart.microfrontends.example.com").hostname}`
};

            

              
                Copy
              
            
          

Pro:

• Più flessibile della configurazione statica.
• Può essere integrato con l'infrastruttura DNS esistente.

Contro:

• Richiede la gestione dei record DNS.
• Può essere lento a propagare le modifiche.
• Si basa sulla disponibilità dell'infrastruttura DNS.

3. Service Registry:

Questo approccio utilizza un service registry dedicato per archiviare la posizione dei micro frontends. I micro frontends si registrano con il service registry all'avvio e i client possono interrogare il service registry per scoprire la loro posizione. Questo è l'approccio più dinamico e resiliente, poiché il service registry può rilevare e rimuovere automaticamente i micro frontends non integri.

I service registry più diffusi includono:

• Consul
• Eureka
• etcd
• ZooKeeper

Esempio (utilizzando Consul):

Innanzitutto, un micro frontend si registra con Consul all'avvio. Ciò comporta in genere la fornitura del nome del micro frontend, dell'indirizzo IP, della porta e di tutti gli altri metadati pertinenti.

            // Esempio che utilizza Node.js e la libreria 'node-consul'
const consul = require('consul')({
  host: 'consul.example.com', // Indirizzo del server Consul
  port: 8500
});

const serviceRegistration = {
  name: 'product-catalog',
  id: 'product-catalog-1',
  address: '192.168.1.10',
  port: 3000,
  check: {
    http: 'http://192.168.1.10:3000/health',
    interval: '10s',
    timeout: '5s'
  }
};

consul.agent.service.register(serviceRegistration, function(err) {
  if (err) throw err;
  console.log('Registered with Consul');
});
            

              
                Copy
              
            
          

Quindi, altri micro frontends o l'applicazione principale possono interrogare Consul per scoprire la posizione del servizio di catalogo prodotti.

            consul.agent.service.list(function(err, result) {
  if (err) throw err;
  const productCatalogService = Object.values(result).find(service => service.Service === 'product-catalog');

  if (productCatalogService) {
    const productCatalogUrl = `http://${productCatalogService.Address}:${productCatalogService.Port}`;
    console.log('Product Catalog URL:', productCatalogUrl);
  } else {
    console.log('Product Catalog service not found');
  }
});
            

              
                Copy
              
            
          

Pro:

• Altamente dinamico e resiliente.
• Supporta i controlli di integrità e il failover automatico.
• Fornisce un punto di controllo centrale per la gestione dei servizi.

Contro:

• Richiede la distribuzione e la gestione di un service registry.
• Aggiunge complessità all'architettura.

4. API Gateway:

Un API gateway funge da singolo punto di ingresso per tutte le richieste ai servizi backend. Può gestire il service discovery, il routing, l'autenticazione e l'autorizzazione. Nel contesto dei microservizi frontend, l'API gateway può essere utilizzato per instradare le richieste al micro frontend appropriato in base al percorso URL o ad altri criteri. L'API Gateway astrae la complessità dei singoli servizi dal client. Aziende come Netflix e Amazon utilizzano ampiamente gli API Gateway.

Esempio:

Immaginiamo di utilizzare un proxy inverso come Nginx come API Gateway. È possibile configurare Nginx per instradare le richieste a diversi micro frontends in base al percorso URL.

            # configurazione nginx

http {
  upstream product_catalog {
    server product-catalog.example.com:8080;
  }

  upstream shopping_cart {
    server shopping-cart.example.com:8081;
  }

  server {
    listen 80;

    location /product-catalog/ {
      proxy_pass http://product_catalog/;
    }

    location /shopping-cart/ {
      proxy_pass http://shopping_cart/;
    }
  }
}

            

              
                Copy
              
            
          

In questa configurazione, le richieste a `/product-catalog/*` vengono instradate all'upstream `product_catalog` e le richieste a `/shopping-cart/*` vengono instradate all'upstream `shopping_cart`. I blocchi upstream definiscono i server backend che gestiscono le richieste.

Pro:

• Punto di ingresso centralizzato per tutte le richieste.
• Gestisce il routing, l'autenticazione e l'autorizzazione.
• Semplifica il service discovery per i client.

Contro:

• Può diventare un collo di bottiglia se non scalato correttamente.
• Aggiunge complessità all'architettura.
• Richiede un'attenta configurazione e gestione.

5. Backend for Frontend (BFF):

Il modello Backend for Frontend (BFF) prevede la creazione di un servizio backend separato per ogni frontend. Ogni BFF è responsabile dell'aggregazione dei dati da più servizi backend e dell'adattamento della risposta alle esigenze specifiche del frontend. In un'architettura a micro frontend, ogni micro frontend può avere il proprio BFF, il che semplifica il recupero dei dati e riduce la complessità del codice frontend. Questo approccio è particolarmente utile quando si ha a che fare con diversi tipi di client (ad es. web, mobile) che richiedono diversi formati di dati o aggregazioni.

Esempio:

Immagina che un'applicazione web e un'app mobile debbano entrambe visualizzare i dettagli del prodotto, ma richiedono dati e formattazione leggermente diversi. Invece di far chiamare direttamente al frontend più servizi backend e gestire la trasformazione dei dati, si crea un BFF per ogni frontend.

Il BFF web potrebbe aggregare i dati da `ProductCatalogService`, `ReviewService` e `RecommendationService` e restituire una risposta ottimizzata per la visualizzazione su uno schermo di grandi dimensioni. Il BFF mobile, d'altra parte, potrebbe recuperare solo i dati più essenziali da `ProductCatalogService` e `ReviewService` per ridurre al minimo l'utilizzo dei dati e ottimizzare le prestazioni sui dispositivi mobili.

Pro:

• Ottimizzato per esigenze frontend specifiche.
• Riduce la complessità sul frontend.
• Consente l'evoluzione indipendente di frontends e backends.

Contro:

• Richiede lo sviluppo e la manutenzione di più servizi backend.
• Può portare alla duplicazione del codice se non gestito correttamente.
• Aumenta i costi operativi.

Strategie di Comunicazione nei Microservizi Frontend

Una volta che i micro frontends sono stati scoperti, devono comunicare tra loro per fornire un'esperienza utente senza interruzioni. Esistono diversi modelli di comunicazione che possono essere utilizzati in un'architettura a microservizi frontend.

Modelli di Comunicazione:

1. Comunicazione Diretta:

In questo modello, i micro frontends comunicano direttamente tra loro utilizzando richieste HTTP o altri protocolli. Questo è il modello di comunicazione più semplice, ma può portare a un accoppiamento stretto e a una maggiore complessità. Può anche portare a problemi di prestazioni se i micro frontends si trovano in reti o regioni diverse.

Esempio:

Un micro frontend (ad esempio, un micro frontend di elenco prodotti) deve visualizzare il numero del carrello della spesa dell'utente corrente, che è gestito da un altro micro frontend (il micro frontend del carrello della spesa). Il micro frontend dell'elenco prodotti può effettuare direttamente una richiesta HTTP al micro frontend del carrello della spesa per recuperare il numero del carrello.

            // Nel micro frontend dell'elenco prodotti:

async function getCartCount() {
  const response = await fetch('https://shopping-cart.example.com/cart/count');
  const data = await response.json();
  return data.count;
}

// ... visualizza il numero del carrello nell'elenco prodotti

            

              
                Copy
              
            
          

Pro:

• Semplice da implementare.

Contro:

• Accoppiamento stretto tra i micro frontends.
• Maggiore complessità.
• Potenziali problemi di prestazioni.
• Difficile gestire le dipendenze.

2. Eventi (Pubblica/Sottoscrivi):

In questo modello, i micro frontends comunicano tra loro pubblicando e sottoscrivendo eventi. Quando un micro frontend pubblica un evento, tutti gli altri micro frontends che sono sottoscritti a quell'evento ricevono una notifica. Questo modello promuove l'accoppiamento debole e consente ai micro frontends di reagire ai cambiamenti in altre parti dell'applicazione senza conoscere i dettagli di tali cambiamenti.

Esempio:

Quando un utente aggiunge un articolo al carrello della spesa (gestito dal micro frontend del carrello della spesa), pubblica un evento chiamato "cartItemAdded". Il micro frontend dell'elenco prodotti, che è sottoscritto a questo evento, aggiorna il numero del carrello visualizzato senza chiamare direttamente il micro frontend del carrello della spesa.

            // Micro Frontend del Carrello della Spesa (Publisher):

function addItemToCart(item) {
  // ... aggiungi l'articolo al carrello
  publishEvent('cartItemAdded', { itemId: item.id });
}

function publishEvent(eventName, data) {
  // ... pubblica l'evento utilizzando un message broker o un event bus personalizzato
}

// Micro Frontend dell'Elenco Prodotti (Subscriber):

subscribeToEvent('cartItemAdded', (data) => {
  // ... aggiorna il numero del carrello visualizzato in base ai dati dell'evento
});

function subscribeToEvent(eventName, callback) {
  // ... sottoscrivi all'evento utilizzando un message broker o un event bus personalizzato
}

            

              
                Copy
              
            
          

Pro:

• Accoppiamento debole tra i micro frontends.
• Maggiore flessibilità.
• Scalabilità migliorata.

Contro:

• Richiede l'implementazione di un message broker o di un event bus.
• Può essere difficile da eseguire il debug.
• La coerenza finale può essere una sfida.

3. Stato Condiviso:

In questo modello, i micro frontends condividono uno stato comune che viene archiviato in una posizione centrale, come un cookie del browser, l'archiviazione locale o un database condiviso. I micro frontends possono accedere e modificare lo stato condiviso, consentendo loro di comunicare tra loro indirettamente. Questo modello è utile per la condivisione di piccole quantità di dati, ma può portare a problemi di prestazioni e a incongruenze dei dati se non gestito correttamente. Prendi in considerazione l'utilizzo di una libreria di gestione dello stato come Redux o Vuex per la gestione dello stato condiviso.

Esempio:

I micro frontends potrebbero condividere il token di autenticazione dell'utente archiviato in un cookie. Ogni micro frontend può accedere al cookie per verificare l'identità dell'utente senza dover comunicare direttamente con un servizio di autenticazione.

            // Impostazione del token di autenticazione (ad esempio, nel micro frontend di autenticazione)

document.cookie = "authToken=your_auth_token; path=/";

// Accesso al token di autenticazione (ad esempio, in altri micro frontends)

function getAuthToken() {
  const cookies = document.cookie.split(';');
  for (let i = 0; i < cookies.length; i++) {
    const cookie = cookies[i].trim();
    if (cookie.startsWith('authToken=')) {
      return cookie.substring('authToken='.length);
    }
  }
  return null;
}

const authToken = getAuthToken();
if (authToken) {
  // ... utilizza il token di autenticazione per autenticare l'utente
}

            

              
                Copy
              
            
          

Pro:

• Semplice da implementare per piccole quantità di dati.

Contro:

• Può portare a problemi di prestazioni.
• Possono verificarsi incongruenze dei dati.
• Difficile gestire le modifiche allo stato.
• Rischi per la sicurezza se non gestito con attenzione (ad esempio, archiviazione di dati sensibili nei cookie).

4. Eventi Finestra (Eventi Personalizzati):

I micro frontends possono comunicare utilizzando eventi personalizzati inviati sull'oggetto `window`. Ciò consente ai micro frontends di interagire anche se vengono caricati in diversi iframe o web component. È un approccio nativo del browser, ma richiede un'attenta gestione dei nomi degli eventi e dei formati dei dati per evitare conflitti e mantenere la coerenza.

Esempio:

            // Micro Frontend A (Publisher)

const event = new CustomEvent('custom-event', { detail: { message: 'Hello from Micro Frontend A' } });
window.dispatchEvent(event);

// Micro Frontend B (Subscriber)

window.addEventListener('custom-event', (event) => {
  console.log('Received event:', event.detail.message);
});
            

              
                Copy
              
            
          

Pro:

• Supporto nativo del browser.
• Relativamente semplice da implementare per la comunicazione di base.

Contro:

• Lo spazio dei nomi globale può portare a conflitti.
• Difficile gestire strutture di eventi complesse.
• Scalabilità limitata per applicazioni di grandi dimensioni.
• Richiede un'attenta coordinazione tra i team per evitare collisioni di nomi.

5. Module Federation (Webpack 5):

Module federation consente a un'applicazione JavaScript di caricare dinamicamente codice da un'altra applicazione in fase di runtime. Consente la condivisione di codice e dipendenze tra diversi micro frontends senza la necessità di pubblicare e utilizzare pacchetti npm. Questo è un approccio potente per la creazione di frontends componibili ed estensibili, ma richiede un'attenta pianificazione e configurazione.

Esempio:

Micro Frontend A (Host) carica un componente da Micro Frontend B (Remote).

            // Micro Frontend A (webpack.config.js)

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... altre configurazioni webpack
  plugins: [
    new ModuleFederationPlugin({
      name: 'MicroFrontendA',
      remotes: {
        'MicroFrontendB': 'MicroFrontendB@http://localhost:3001/remoteEntry.js',
      },
      shared: ['react', 'react-dom'], // Condividi le dipendenze per evitare duplicati
    }),
  ],
};

// Micro Frontend A (Component)

import React from 'react';
import RemoteComponent from 'MicroFrontendB/Component';

const App = () => {
  return (
    

      
Micro Frontend A
      
    
  );
};

export default App;

// Micro Frontend B (webpack.config.js)

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... altre configurazioni webpack
  plugins: [
    new ModuleFederationPlugin({
      name: 'MicroFrontendB',
      exposes: {
        './Component': './src/Component',
      },
      shared: ['react', 'react-dom'],
    }),
  ],
};

// Micro Frontend B (src/Component.js)

import React from 'react';

const Component = () => {
  return 
Hello from Micro Frontend B!
;
};

export default Component;
            

              
                Copy
              
            
          

Pro:

• Condivisione e riutilizzo del codice senza pacchetti npm.
• Caricamento dinamico dei componenti in fase di runtime.
• Tempi di compilazione e efficienza della distribuzione migliorati.

Contro:

• Richiede Webpack 5 o versioni successive.
• Può essere complesso da configurare.
• Possono sorgere problemi di compatibilità della versione con le dipendenze condivise.

6. Web Components:

I Web Components sono un insieme di standard web che consentono di creare elementi HTML personalizzati riutilizzabili con stile e comportamento incapsulati. Forniscono un modo indipendente dalla piattaforma per creare micro frontends che possono essere integrati in qualsiasi applicazione web, indipendentemente dal framework sottostante. Pur offrendo un'eccellente incapsulamento, potrebbero richiedere strumenti o framework aggiuntivi per gestire scenari complessi di gestione dello stato o data binding.

Esempio:

            // Micro Frontend A (Web Component)

class MyCustomElement extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' }); // DOM ombra incapsulato
    this.shadowRoot.innerHTML = `
      
      
Hello from Web Component!
    `;
  }
}

customElements.define('my-custom-element', MyCustomElement);

// Utilizzo del Web Component in qualsiasi pagina HTML


            

              
                Copy
              
            
          

Pro:

• Indipendente dal framework e riutilizzabile in diverse applicazioni.
• Stile e comportamento incapsulati.
• Tecnologia web standardizzata.

Contro:

• Può essere prolisso da scrivere senza una libreria di supporto.
• Potrebbe richiedere polyfill per i browser meno recenti.
• La gestione dello stato e il data binding possono essere più complessi rispetto alle soluzioni basate su framework.

Scegliere la Strategia Giusta

La migliore strategia di service discovery e comunicazione per la tua architettura a microservizi frontend dipende da diversi fattori, tra cui:

• Le dimensioni e la complessità della tua applicazione. Per le applicazioni più piccole, un approccio semplice come la configurazione statica o la comunicazione diretta può essere sufficiente. Per le applicazioni più grandi e complesse, si consiglia un approccio più solido come un service registry o un'architettura basata sugli eventi.
• Il livello di autonomia richiesto dai tuoi team. Se i team devono essere altamente autonomi, è preferibile un modello di comunicazione a basso accoppiamento come gli eventi. Se i team possono coordinarsi più strettamente, può essere accettabile un modello più strettamente accoppiato come la comunicazione diretta.
• I requisiti di prestazioni della tua applicazione. Alcuni modelli di comunicazione, come la comunicazione diretta, possono essere più performanti di altri, come gli eventi. Tuttavia, i vantaggi in termini di prestazioni della comunicazione diretta possono essere compensati dalla maggiore complessità e dall'accoppiamento stretto.
• La tua infrastruttura esistente. Se hai già un service registry o un message broker in atto, ha senso sfruttare tale infrastruttura per i tuoi microservizi frontend.

Best Practice

Ecco alcune best practice da seguire quando implementi il service discovery e la comunicazione nella tua architettura a microservizi frontend:

• Mantieni la semplicità. Inizia con l'approccio più semplice che soddisfi le tue esigenze e aumenta gradualmente la complessità secondo necessità.
• Prediligi l'accoppiamento debole. L'accoppiamento debole rende la tua applicazione più flessibile, resiliente e facile da mantenere.
• Utilizza un modello di comunicazione coerente. L'utilizzo di un modello di comunicazione coerente tra i tuoi micro frontends rende la tua applicazione più facile da comprendere ed eseguire il debug.
• Monitora i tuoi servizi. Monitora lo stato e le prestazioni dei tuoi micro frontends per assicurarti che funzionino correttamente.
• Implementa una robusta gestione degli errori. Gestisci gli errori in modo appropriato e fornisci messaggi di errore informativi agli utenti.
• Documenta la tua architettura. Documenta i modelli di service discovery e comunicazione utilizzati nella tua applicazione per aiutare altri sviluppatori a comprenderla e mantenerla.

Conclusione

I microservizi frontend offrono vantaggi significativi in termini di scalabilità, manutenibilità e autonomia del team. Tuttavia, l'implementazione di un'architettura a micro frontend di successo richiede un'attenta considerazione delle strategie di service discovery e comunicazione. Scegliendo gli approcci giusti e seguendo le best practice, puoi creare un frontend robusto e flessibile che soddisfi le esigenze dei tuoi utenti e dei tuoi team di sviluppo.

La chiave per un'implementazione di successo dei micro frontends risiede nella comprensione dei compromessi tra i diversi modelli di service discovery e comunicazione. Mentre la configurazione statica offre semplicità, manca della dinamicità di un service registry. La comunicazione diretta può sembrare semplice, ma può portare a un accoppiamento stretto, mentre le architetture guidate dagli eventi promuovono un accoppiamento debole, ma introducono complessità in termini di message brokering e coerenza finale. Module federation offre un modo potente per condividere il codice, ma richiede una moderna toolchain di build. Allo stesso modo, i web component forniscono un approccio standardizzato, tuttavia potrebbero aver bisogno di essere integrati da framework quando si gestiscono lo stato e il data binding.

In definitiva, la scelta ottimale dipende dai requisiti specifici del progetto, dalle competenze del team e dagli obiettivi architetturali generali. Una strategia ben pianificata, combinata con l'adesione alle best practice, può portare a un'architettura a micro frontend robusta e scalabile che offre un'esperienza utente superiore.