Cos'è il pattern BFF (Backend for Frontend)?

Il Backend for Frontend (BFF) è un pattern architetturale che prevede la creazione di servizi backend dedicati e specifici per ogni tipo di interfaccia frontend. Invece di avere un unico backend generico che serve tutte le piattaforme, il pattern BFF introduce un layer intermedio che ottimizza le API per le esigenze specifiche di ciascun client: web, mobile, smart TV, IoT, ecc.

Il pattern BFF è stato formalizzato da Sam Newman nel 2015, nell'articolo "Backends for Frontends" e successivamente nel libro "Building Microservices" (O'Reilly, 2015). Newman lo ha descritto come evoluzione naturale del pattern API Gateway per architetture microservizi.

Secondo ThoughtWorks Technology Radar (2023), il pattern BFF è classificato nella categoria Adopt ed è ampiamente utilizzato da aziende come Netflix, SoundCloud, Spotify e Airbnb.

Il problema del "One Size Fits All"

Un backend unico per tutti i frontend presenta diversi problemi:

Esempio pratico

Una pagina prodotto in un e-commerce:

• Web desktop: Mostra immagini HD, recensioni complete, prodotti correlati, video
• Mobile app: Mostra immagini ottimizzate, rating sintetico, prezzo, CTA
• Smart watch: Mostra solo nome, prezzo e disponibilità

Con un'API unica, il mobile scaricherebbe dati inutili (video, recensioni complete) sprecando banda e batteria. Con BFF, ogni client ha un'API ottimizzata.

Architettura base

[Web App] → [Web BFF] ──┐ ├──→ [Microservizi Backend] [Mobile App] → [Mobile BFF] ──┘

Architettura avanzata

[React SPA] → [Web BFF] ──────────┐ [iOS App] → [iOS BFF] ────────────┤ [Android App] → [Android BFF] ────┼──→ [Product Service] [Smart TV] → [TV BFF] ────────────┤ [Order Service] [Chatbot] → [Conversational BFF] ─┘ [User Service] [Payment Service] 

BFF vs. API Gateway

Nella pratica, BFF e API Gateway coesistono:

[Frontend] → [API Gateway] → [BFF] → [Microservizi]

Responsabilità del BFF

1. Aggregazione — combinare dati da più microservizi in una singola risposta
2. Trasformazione — adattare il formato dei dati alle esigenze del frontend
3. Ottimizzazione — minimizzare il numero di chiamate e la quantità di dati
4. Caching — cache specifica per il pattern di utilizzo del frontend
5. Autenticazione — gestione sessione specifica per piattaforma
6. Error handling — traduzione degli errori in formato comprensibile al frontend

Tecnologie comuni

GraphQL come alternativa al BFF

GraphQL può fungere da alternativa al pattern BFF tradizionale:

• Il frontend chiede esattamente i dati di cui ha bisogno
• Elimina over-fetching e under-fetching
• Un singolo endpoint per tutti i frontend
• Tuttavia, la complessità si sposta nel resolver layer

Molti team utilizzano GraphQL come BFF, combinando i vantaggi di entrambi gli approcci.

Vantaggi

Svantaggi

BFF è indicato quando:

• Avete multiple piattaforme con esigenze diverse (web, mobile, IoT)
• I team frontend sono separati dai team backend
• Le API esistenti richiedono troppe chiamate dal frontend
• La performance mobile è critica
• Volete disaccoppiare l'evoluzione del frontend dal backend

BFF NON è indicato quando:

• Avete un singolo frontend
• Il backend è semplice con pochi microservizi
• Non avete risorse per mantenere servizi aggiuntivi
• L'applicazione è un CRUD semplice

Netflix

Netflix utilizza BFF per ottimizzare l'esperienza su 1.500+ tipi di dispositivi: TV, console, mobile, browser. Ogni tipo di dispositivo ha un BFF che aggrega dati dal catalogo, raccomandazioni e profilo utente.

SoundCloud

SoundCloud ha adottato il BFF per separare le esigenze del web player da quelle delle app mobile, permettendo ai team di evolvere indipendentemente.

Spotify

Spotify utilizza BFF per ottimizzare le risposte per diverse esperienze: app mobile, desktop app, web player, car display, smart speaker.

• Il 67% delle aziende con architettura microservizi utilizza qualche forma di BFF (InfoQ, 2023)
• L'adozione del BFF riduce le chiamate API del frontend del 40–60% (ThoughtWorks, 2023)
• I team con BFF rilasciano aggiornamenti frontend 2x più velocemente (Accelerate, 2023)
• Netflix gestisce più di 200 BFF per i suoi diversi client (Netflix Tech Blog, 2022)
• Il pattern BFF riduce il tempo di caricamento mobile del 30–50% rispetto a un API monolitico

Chi è proprietario del BFF?

Il BFF dovrebbe essere proprietà del team frontend che lo utilizza. Questo garantisce che le API siano ottimizzate per le reali esigenze del frontend e che il team possa evolverle autonomamente.

Quanti BFF dovrei avere?

La regola generale è un BFF per tipo di esperienza utente: uno per web, uno per iOS, uno per Android, ecc. Non è necessario un BFF per ogni singola pagina o componente.

Il BFF sostituisce l'API Gateway?

No. BFF e API Gateway hanno responsabilità diverse e tipicamente coesistono. L'API Gateway gestisce cross-cutting concerns (autenticazione, rate limiting), mentre il BFF gestisce aggregazione e trasformazione dati.

Come gestisco la duplicazione tra BFF?

Utilizzate librerie condivise per logica comune (autenticazione, logging, error handling) e mantenete solo la logica specifica per frontend dentro ogni BFF.

Posso usare GraphQL al posto del BFF?

GraphQL può essere un'alternativa valida al BFF tradizionale, specialmente se avete un singolo team che gestisce tutti i frontend. Tuttavia, per team separati con esigenze molto diverse, BFF dedicati offrono maggiore autonomia.

• Microservizi
• API
• DevOps
• CI/CD
• Architettura Esagonale
• DDD — Domain-Driven Design
• Frontend