Modelli back-end per front-end

Articolo
2025-05-15

Questo modello descrive come 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 è basato sul modello Back-end per front-end di 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, viene aggiunta un'interfaccia mobile. Entrambe le interfacce interagiscono con lo stesso servizio back-end. Tuttavia, 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.

Un servizio back-end incontra spesso richieste concorrenti da più sistemi front-end. Queste richieste comportano aggiornamenti frequenti e potenziali ostacoli nello sviluppo. Gli aggiornamenti in conflitto e la necessità di mantenere la compatibilità comportano una domanda eccessiva 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. Questa disconnessione può causare ritardi nell'ottenere requisiti di consenso e bilanciamento. 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, noto come 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, ad esempio un'interfaccia Web e un'app per dispositivi mobili, creare un servizio BFF per ogni interfaccia.

Questo modello consente di personalizzare l'esperienza client per un'interfaccia specifica senza influire sulle altre interfacce. Ottimizza anche le prestazioni per soddisfare le esigenze dell'ambiente front-end. Poiché ogni servizio BFF è più piccolo e meno complesso di un servizio back-end condiviso, può semplificare la gestione dell'applicazione.

I team front-end gestiscono in modo indipendente il proprio servizio BFF, che consente loro di controllare la selezione del linguaggio, la frequenza di rilascio, la definizione delle priorità dei carichi di lavoro e l'integrazione delle funzionalità. Questa autonomia consente loro di operare in modo efficiente senza dipendere da un team di sviluppo back-end centralizzato.

Molti servizi BFF tradizionalmente si basavano sulle API REST, ma ora le implementazioni di GraphQL stanno emergendo come un'alternativa. Con GraphQL, il meccanismo di query elimina la necessità di un livello BFF separato perché consente ai client di richiedere i dati necessari senza basarsi su endpoint predefiniti.

Per altre informazioni, vedere Modelli back-end per front-end di Sam Newman.

Problemi e considerazioni

Valutare il numero ottimale di servizi in base ai costi 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 a livello di servizio quando si aggiunge un nuovo servizio. Potrebbe verificarsi una maggiore latenza 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 personalizzata migliore 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 l'efficienza. Le funzionalità tipiche che potrebbero emergere nel servizio BFF vengono gestite separatamente con i modelli gatekeeping, rate limit e routing .
Valutare il modo in cui l'apprendimento e l'implementazione di questo modello influiscono sul team di sviluppo. Lo sviluppo di nuovi sistemi back-end richiede tempo e impegno, il che può comportare un debito tecnico. La gestione del servizio back-end esistente aggiunge a questa sfida.
Valutare se è necessario questo modello. Ad esempio, se l'organizzazione usa GraphQL con resolver specifici front-end, i servizi BFF potrebbero non aggiungere valore alle applicazioni.

Un altro scenario è un'applicazione che combina un gateway API con microservizi. Questo approccio potrebbe essere sufficiente per alcuni scenari in cui i servizi BFF sono in genere consigliati.

Quando usare questo modello

Usare questo modello quando:

Un servizio back-end condiviso o per utilizzo generico richiede un notevole sovraccarico di sviluppo da gestire.
Si vuole ottimizzare il back-end per i requisiti di interfacce client specifiche.
È possibile apportare personalizzazioni a 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 quando:

Le interfacce effettuano le stesse richieste o simili al back-end.
Solo un'interfaccia interagisce con il back-end.

Progettazione del carico di lavoro

Valutare come usare il modello Back-end per i front-end nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro	Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto.	Quando si isolano i servizi in un'interfaccia front-end specifica, sono presenti malfunzionamenti. La disponibilità di un client non influisce sulla disponibilità dell'accesso di un altro client. Quando si gestiscono 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 Autoconservazione
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.	La separazione dei servizi introdotta in questo modello consente la personalizzazione della sicurezza e dell'autorizzazione nel livello di servizio per le esigenze specifiche di ogni client. Questo approccio può ridurre la superficie dell'API e limitare lo spostamento laterale tra backend che potrebbero offrire diverse capacità. - Segmentazione SE:04 - Risorse di protezione avanzata SE:08
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e 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

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Esempio

Questo esempio illustra un caso d'uso per il modello in cui due applicazioni client distinte, un'app per dispositivi mobili e un'applicazione desktop, interagiscono con Gestione API di Azure (gateway del piano dati). Questo gateway funge da livello di astrazione e gestisce preoccupazioni comuni trasversali, ad esempio:

Autorizzazione. Garantisce che solo le identità verificate con i token di accesso appropriati possano chiamare risorse protette usando Gestione API con Microsoft Entra ID.
Monitoraggio. Acquisisce e invia i dettagli delle richieste e delle risposte ad Azure Monitor per scopi di osservabilità.
Memorizzazione nella cache delle richieste. Ottimizza le richieste ripetute servendo le risposte dalla cache tramite funzionalità predefinite di Gestione API.
Routing e aggregazione. Indirizza le richieste in ingresso ai servizi BFF appropriati.

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 servizi BFF specifici del client garantiscono un'esperienza personalizzata per la paginazione e altre funzionalità. L'app per dispositivi mobili assegna priorità all'efficienza della larghezza di banda e sfrutta la memorizzazione nella cache per migliorare le prestazioni. Al contrario, l'applicazione desktop recupera più pagine in una singola richiesta, che crea un'esperienza utente più immersiva.

Flow A per la prima richiesta di pagina dal client per dispositivi mobili

Il client mobile invia una richiesta per la pagina GET1, includendo il token OAuth 2.0 nell'intestazione dell'autorizzazione.
La richiesta raggiunge il gateway di Gestione API, che lo intercetta e:
1. Controlla lo stato dell'autorizzazione. Gestione API implementa la difesa in profondità, in modo da verificare la validità del token di accesso.
2. Trasmette l'attività della richiesta come log ad Azure Monitor. I dettagli della richiesta vengono registrati per il controllo e il monitoraggio.
I criteri vengono applicati, quindi Gestione API instrada la richiesta al servizio BFF mobile per le funzioni di Azure.
Il servizio BFF per le funzioni di Azure 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.

Flusso B per la richiesta della prima pagina memorizzata nella cache dal client mobile

Il client mobile invia nuovamente la stessa richiesta GET per la pagina 1, includendo il token OAuth 2.0 nell'intestazione dell'autorizzazione.
Il gateway di Gestione API riconosce che questa richiesta è stata effettuata in precedenza e:
1. I criteri vengono applicati. Il gateway identifica quindi una risposta memorizzata nella cache che corrisponde ai parametri della richiesta.
2. Restituisce immediatamente la risposta memorizzata nella cache. Questa risposta rapida elimina la necessità di inoltrare la richiesta al servizio BFF mobile per le funzioni di Azure.

Flow C per la prima richiesta dal client desktop

Il client desktop invia una GET richiesta per la prima volta, includendo il token OAuth 2.0 nell'intestazione dell'autorizzazione.
La richiesta raggiunge il gateway di Gestione API, in cui vengono gestiti i problemi trasversali.
1. Autorizzazione: La convalida dei token è sempre obbligatoria.
2. Trasmettere l'attività della richiesta: I dettagli della richiesta vengono registrati per l'osservabilità.
Dopo l'applicazione di tutti i criteri, Gestione API instrada la richiesta al servizio BFF desktop delle funzioni di Azure, che gestisce l'elaborazione di applicazioni con elevato utilizzo di dati. Il servizio BFF desktop 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. Fornisce attestazioni di destinatari personalizzate sia per i client per dispositivi mobili che per i client desktop. Queste attestazioni vengono quindi usate per l'autorizzazione.
Gestione API funge da proxy tra i client e i relativi servizi BFF, che stabilisce un perimetro. Gestione API è configurato con criteri per convalidare i token Web JSON e rifiuta le richieste che non dispongono di un token o contengono attestazioni non valide per il servizio BFF di destinazione. Trasmette anche tutti i log delle attività ad Azure Monitor.
Azure Monitor funziona come soluzione centrale di monitoraggio. Aggrega tutti i log delle attività per garantire un'osservabilità completa end-to-end.
Funzioni di Azure è una soluzione serverless che espone in modo efficiente la logica del servizio BFF tra più endpoint, semplificando lo sviluppo. Funzioni di Azure riduce anche il sovraccarico dell'infrastruttura e riduce i costi operativi.

Condividi tramite