Separare i servizi back-end dalle implementazioni front-end per personalizzare le esperienze per interfacce client diverse. Questo modello è utile quando si vuole evitare di personalizzare un back-end che gestisce più interfacce. Questo modello si basa sul modello di : back-end per i front-end descritto da Sam Newman.
Contesto e problema
Si consideri un'applicazione progettata inizialmente con un'interfaccia utente Web desktop e un servizio back-end corrispondente. Man mano che i requisiti aziendali cambiano nel tempo, è stata aggiunta un'interfaccia mobile. Entrambe le interfacce interagiscono con lo stesso servizio back-end, ma le funzionalità di un dispositivo mobile differiscono in modo significativo da un browser desktop, in termini di dimensioni dello schermo, prestazioni e limitazioni di visualizzazione.
Il servizio back-end spesso affronta richieste concorrenti da diversi front-end, causando frequenti modifiche e potenziali colli di bottiglia nel processo di sviluppo. Gli aggiornamenti in conflitto e la necessità di mantenere la compatibilità comportano un lavoro eccessivo su una singola risorsa distribuibile.
La gestione del servizio back-end da parte di un team separato può creare una disconnessione tra i team front-end e back-end, causando ritardi nell'acquisizione del consenso e del bilanciamento dei requisiti. Ad esempio, le modifiche richieste da un team front-end devono essere convalidate con altri team front-end prima dell'integrazione.
Soluzione
Introdurre un nuovo livello che gestisce solo i requisiti specifici dell'interfaccia. Questo livello denominato servizio back-end per front-end (BFF) si trova tra il client front-end e il servizio back-end. Se l'applicazione supporta più interfacce, creare un servizio BFF per ogni interfaccia. Ad esempio, se si dispone di un'interfaccia Web e di un'app per dispositivi mobili, è necessario creare servizi BFF separati per ognuno di essi.
Questo modello consente di personalizzare l'esperienza client per un'interfaccia specifica, senza influire sulle altre interfacce. Ottimizza anche le prestazioni in base alle esigenze dell'ambiente front-end. Poiché ogni servizio BFF è più piccolo e meno complesso, l'applicazione potrebbe sperimentare vantaggi di ottimizzazione fino a un certo punto.
I team front-end hanno autonomia rispetto al proprio servizio BFF, consentendo flessibilità nella selezione del linguaggio, nella frequenza di rilascio, nella definizione delle priorità dei carichi di lavoro e nell'integrazione delle funzionalità senza basarsi su un team di sviluppo back-end centralizzato.
Anche se molte funzioni ADF si basavano sulle API REST, le implementazioni di GraphQL stanno diventando un'alternativa, eliminando così la necessità del livello BFF perché il meccanismo di query non richiede un endpoint separato.
Per altre informazioni, vedere modello di : back-end per front-end.
Problemi e considerazioni
Valutare il numero ottimale di servizi, in quanto i costi associati saranno associati. La gestione e la distribuzione di più servizi comportano un aumento del sovraccarico operativo. Ogni singolo servizio ha un proprio ciclo di vita, requisiti di distribuzione e manutenzione e esigenze di sicurezza.
Esaminare gli obiettivi del livello di servizio durante l'aggiunta di un nuovo servizio. Una maggiore latenza può verificarsi perché i client non contattano direttamente i servizi e il nuovo servizio introduce un hop di rete aggiuntivo.
Quando interfacce diverse effettuano le stesse richieste, valutare se le richieste possono essere consolidate in un singolo servizio BFF. La condivisione di un singolo servizio BFF tra più interfacce può comportare requisiti diversi per ogni client, che può complicare la crescita e il supporto del servizio BFF.
La duplicazione del codice è un risultato probabile di questo modello. Valutare il compromesso tra la duplicazione del codice e un'esperienza più personalizzata per ogni client.
Il servizio BFF deve gestire solo la logica specifica del client correlata a un'esperienza utente specifica. Le funzionalità trasversali, ad esempio il monitoraggio e l'autorizzazione, devono essere astratte per mantenere la luce del servizio BFF. Le funzionalità tipiche che potrebbero essere presenti nel servizio BFF vengono gestite separatamente con Gatekeeping, Rate Limit, Routinge altri.
Prendere in considerazione l'impatto sul team di sviluppo durante l'apprendimento e l'implementazione di questo modello. La creazione di nuovi back-end richiede tempo e impegno, potenzialmente incorrere in debito tecnico mantenendo il servizio back-end esistente.
Valutare se è necessario questo modello. Ad esempio, se l'organizzazione usa GraphQL con resolver specifici del front-end, BFF potrebbe non aggiungere valore alle applicazioni.
Un altro esempio è l'applicazione che combina gateway API con i microservizi. Questo approccio può essere sufficiente per alcuni casi in cui sono stati consigliati in precedenza i file BFF.
Quando usare questo modello
Usare questo modello quando:
Un servizio back-end condiviso o per utilizzo generico deve essere gestito con un sovraccarico di sviluppo significativo.
Si vuole ottimizzare il back-end per i requisiti di interfacce client specifiche.
Le personalizzazioni vengono eseguite in un back-end per utilizzo generico per supportare più interfacce.
Un linguaggio di programmazione è più adatto per il back-end di un'interfaccia utente specifica, ma non per tutte le interfacce utente.
Questo modello potrebbe non essere adatto nelle situazioni seguenti:
Quando le interfacce effettuano le stesse richieste o simili al back-end.
Quando viene usata una sola interfaccia per interagire con il back-end.
Progettazione del carico di lavoro
Un architetto deve valutare come usare il modello Back-end per i front-end nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework di azure . Per esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. | La presenza di servizi separati esclusivi di un'interfaccia front-end specifica contiene malfunzionamenti, pertanto la disponibilità di un client potrebbe non influire sulla disponibilità dell'accesso di un altro client. Inoltre, quando si trattano diversi client in modo diverso, è possibile classificare in ordine di priorità le attività di affidabilità in base ai modelli di accesso client previsti. - Flussi critici RE:02 - RE:07 Conservazione automatica |
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | A causa della separazione dei servizi introdotta in questo modello, la sicurezza e l'autorizzazione nel livello di servizio che supporta un client possono essere personalizzate in base alle funzionalità richieste da tale client, riducendo potenzialmente l'area di superficie di un'API e lo spostamento laterale tra diversi back-end che potrebbero esporre funzionalità diverse. - SE:04 Segmentazione - Risorse di protezione avanzata SE:08 |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | La separazione back-end consente di ottimizzare in modi che potrebbero non essere possibili con un livello di servizio condiviso. Quando si gestiscono singoli client in modo diverso, è possibile ottimizzare le prestazioni per i vincoli e le funzionalità di un client specifico. - PE:02 Pianificazione della capacità - flussi critici PE:09 |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
Questo esempio mostra un caso d'uso per il modello in cui sono presenti due applicazioni client distinte: un'app per dispositivi mobili e un'applicazione desktop. Entrambi i client interagiscono con gestione API di Azure (gateway del piano dati), che funge da livello di astrazione, gestendo problemi comuni di taglio incrociato, ad esempio:
di autorizzazione: garantire che solo le identità verificate con i token di accesso appropriati possano chiamare risorse protette usando Gestione API di Azure (APIM) con Microsoft Entra ID.
Monitoraggio: acquisizione e invio di dettagli di richiesta e risposta per scopi di osservabilità a Monitoraggio di Azure.
la memorizzazione nella cache delle richieste: ottimizzazione delle richieste ripetute tramite la gestione delle risposte dalla cache tramite le funzionalità predefinite di Gestione API.
routing & aggregazione: indirizzamento delle richieste in ingresso al back-end appropriato per i servizi front-end (BFF).
Ogni client ha un servizio BFF dedicato in esecuzione come funzione di Azure che funge da intermediario tra il gateway e i microservizi sottostanti. Questi BFF specifici del client garantiscono un'esperienza personalizzata per la paginazione, tra le altre funzionalità. Anche se il dispositivo mobile è più consapevole della larghezza di banda e la memorizzazione nella cache migliora le prestazioni, il desktop aggrega più pagine in una singola richiesta, ottimizzando per un'esperienza utente più completa.
Il diagramma è strutturato in quattro sezioni distinte, che illustrano il flusso di richieste, autenticazione, monitoraggio e elaborazione specifica del client. All'estrema sinistra, due dispositivi client avviano le richieste: un'applicazione per dispositivi mobili ottimizzata per un'esperienza utente efficiente per la larghezza di banda e un Web browser che offre un'interfaccia completamente funzionale. Le frecce si estendono da entrambi i dispositivi verso il punto di ingresso centrale, ovvero il gateway di Gestione API di Azure, a indicare che tutte le richieste devono passare attraverso questo livello. All'interno della seconda sezione, racchiusa in un rettangolo linea tratteggiata, l'architettura è divisa in due gruppi orizzontali. Il gruppo a sinistra rappresenta Gestione API di Azure, responsabile della gestione delle richieste in ingresso e della modalità di elaborazione. Due frecce si estendono verso l'esterno da questo gateway del piano dati: uno che punta verso l'alto verso l'alto, che gestisce l'autorizzazione, e un altro che punta verso il basso a Monitoraggio di Azure, responsabile della registrazione e dell'osservabilità. Inoltre, una freccia torna dal gateway al client mobile, che rappresenta una risposta memorizzata nella cache quando viene ripetuta una richiesta identica, riducendo l'elaborazione non necessaria. Il gruppo destro all'interno del rettangolo tratteggiato è incentrato su come personalizzare le risposte back-end in base al tipo di client che effettua la richiesta. Offre due client back-end separati per front-end, entrambi ospitati con Funzioni di Azure per l'elaborazione serverless, uno dedicato al client mobile e l'altro al client desktop. Due frecce si estendono dal gateway a questi client back-end per front-end, illustrando che ogni richiesta in ingresso viene inoltrata al servizio appropriato a seconda del tipo di client. Oltre questo livello, le frecce tratteggiate si estendono ulteriormente a destra, collegando i client back-end per front-end a vari microservizi, che gestiscono la logica di business effettiva. Per visualizzare questo diagramma, si immagini un flusso da sinistra a destra in cui le richieste client passano da client mobili e Web al gateway. Questo gateway elabora ogni richiesta delegando l'autenticazione verso l'alto al provider di identità e registrandosi verso il basso al servizio di monitoraggio. Da qui, instrada le richieste al client back-end appropriato per il front-end in base al fatto che la richiesta abbia origine da un client mobile o desktop. Infine, ogni client back-end per front-end inoltra la richiesta a microservizi specializzati, che eseguono la logica di business richiesta e restituiscono la risposta necessaria. Se è disponibile una risposta memorizzata nella cache, il gateway intercetta la richiesta e invia la risposta archiviata direttamente al client mobile, impedendo l'elaborazione ridondante.
Flow A: Client per dispositivi mobili - richiesta di prima pagina
- Il client mobile invia una richiesta di
GETper la pagina1incluso il token OAuth 2.0 nell'intestazione dell'autorizzazione. - La richiesta raggiunge il gateway di Gestione API di Azure, che lo intercetta e:
- Controlla lo stato dell'autorizzazione: Gestione API implementa la difesa in profondità, in modo da verificare la validità del token di accesso.
- Trasmettere l'attività della richiesta come log a Monitoraggio di Azure: i dettagli della richiesta vengono registrati per il controllo e il monitoraggio.
- I criteri vengono applicati, quindi Gestione API di Azure instrada la richiesta al BFF mobile per le funzioni di Azure.
- Azure Function Mobile BFF interagisce quindi con i microservizi necessari per recuperare una singola pagina ed elaborare i dati richiesti per offrire un'esperienza leggera.
- La risposta viene restituita al client.
Flow B: client per dispositivi mobili - prima pagina richiesta memorizzata nella cache
- Il client mobile invia nuovamente la stessa richiesta di
GETper la pagina1includendo il token OAuth 2.0 nell'intestazione dell'autorizzazione. - Il gateway di Gestione API di Azure riconosce che questa richiesta è stata effettuata in precedenza e:
- I criteri vengono applicati e, dopo, identifica una risposta memorizzata nella cache corrispondente ai parametri della richiesta.
- Restituisce immediatamente la risposta memorizzata nella cache, eliminando la necessità di inoltrare la richiesta a Azure Function Mobile BFF.
Flow C: client desktop - prima richiesta
- Il client desktop invia una richiesta di
GETper la prima volta, incluso il token OAuth 2.0 nell'intestazione dell'autorizzazione. - La richiesta raggiunge il gateway di Gestione API di Azure, in cui vengono gestite problematiche trasversali simili:
- Autorizzazione: la convalida del token è sempre necessaria.
- Trasmettere l'attività della richiesta: i dettagli della richiesta vengono registrati per l'osservabilità.
- Dopo l'applicazione di tutti i criteri, Gestione API di Azure instrada la richiesta al BFF di Desktop delle funzioni di Azure, responsabile della gestione dell'elaborazione di applicazioni con elevato carico di dati. Desktop BFF aggrega più richieste usando le chiamate di microservizi sottostanti prima di rispondere al client con una risposta a più pagine.
Progettazione
microsoft Entra ID funge da provider di identità basato sul cloud, rilasciando attestazioni di destinatari personalizzate per client per dispositivi mobili e desktop, che vengono successivamente sfruttati per l'autorizzazione.
Gestione API di Azure funge da proxy tra i client e i relativi BBF aggiungendo un perimetro. È configurato con i criteri per convalidare i token JSON Web (JWT), rifiutando le richieste che arrivano senza un token o le attestazioni non sono valide per il BFF di destinazione. Trasmette inoltre tutti i log attività a Monitoraggio di Azure.
Monitoraggio di Azure funziona come soluzione di monitoraggio centralizzata, aggregando tutti i log attività per garantire un'osservabilità completa e end-to-end.
Funzioni di Azure è una soluzione serverless che espone senza problemi la logica BFF tra più endpoint, consentendo lo sviluppo semplificato, riducendo il sovraccarico dell'infrastruttura e riducendo i costi operativi.
Passaggi successivi
- modello : back-end per i front-end