API gateway vs BFF per client web e mobile: compromessi

Il problema: un solo backend, molti client, esigenze diverse

Un punto di partenza comune è semplice: un backend espone un set di endpoint e sia l'app web che quella mobile li chiamano. Sembra efficiente perché c'è un unico posto dove aggiungere funzionalità, correggere bug e applicare regole.

Poi arriva la realtà. L'interfaccia web spesso richiede schermate dense, filtri, esportazioni e azioni di amministrazione. Il mobile di solito necessita di meno campi, schermate più veloci, flussi offline-friendly e attenzione a batteria e consumo dati. Anche quando la funzionalità è "la stessa", la forma migliore dell'API per ogni client raramente è identica.

Col tempo, gli endpoint si scostano. Il team web aggiunge campi extra per una nuova vista a tabella. Il mobile chiede di togliere payload pesanti e combinare più chiamate in una sola. Qualcuno aggiunge un parametro "solo per iOS". Un altro riusa un endpoint admin interno nell'app pubblica perché era "già lì". Quello che era un'API pulita diventa una collezione di compromessi.

I rischi emergono in fretta:

• Breaking change quando un client rilascia più velocemente dell'altro
• App più lente per payload grandi o troppi round trip
• Codice backend più complesso perché ogni endpoint cerca di servire ogni client
• Esposizione accidentale di dati quando campi o azioni interne filtrano nelle API pubbliche
• Versioning doloroso perché "piccoli cambi" non sono piccoli per i client più vecchi

Questa è la tensione centrale nella discussione API gateway vs BFF. Vuoi API pubbliche stabili su cui mobile e web possano contare, lasciando però a ogni client lo spazio per evolvere al proprio ritmo.

API gateway e BFF: cosa sono (e cosa non sono)

Un API gateway è una porta d'ingresso per le tue API. I client chiamano il gateway, che instrada le richieste al servizio backend giusto. Spesso gestisce preoccupazioni condivise che non vuoi ripetere ovunque, come controlli di autenticazione, rate limit, logging delle richieste e shaping basilare delle richieste.

Un backend-for-frontend (BFF) è un piccolo backend costruito per uno specifico client o gruppo di client, come "web" e "mobile". Il client chiama il suo BFF e il BFF chiama i servizi sottostanti. L'idea chiave è la focalizzazione: il BFF è autorizzato a parlare il linguaggio del client (schermate, flussi e payload), anche se i servizi core restano più generici.

Questi pattern non sostituiscono servizi di dominio ben fatti o un modello dati pulito. I tuoi servizi core, database e regole di business dovrebbero rimanere la fonte di verità. Un gateway o un BFF non devono trasformarsi in un grosso ammasso di logica di business che piano piano diventa il tuo vero backend.

Un modo semplice per distinguerli:

• Gateway: un punto d'ingresso unico, preoccupazioni condivise, routing e protezione
• BFF: API specifiche per client che riducono il lavoro lato client e nascondono la complessità interna

Li puoi anche combinare. Una configurazione comune è un gateway come edge pubblico, con BFF separati dietro di esso per web e mobile. Il gateway gestisce sicurezza esterna e regole di traffico, mentre ogni BFF modella endpoint e risposte per il suo client.

Come cambia il percorso di una richiesta in ogni pattern

La differenza principale tra un API gateway e un BFF è dove metti la logica di "porta d'ingresso": routing, controlli di autenticazione e shaping delle risposte.

Con un API gateway il client di solito parla a un punto d'ingresso condiviso. Il gateway inoltra le richieste ai servizi interni, svolgendo spesso compiti di base come validazione token, rate limit e routing per path.

Con un BFF, ogni tipo di client (web, iOS, Android) chiama un backend costruito appositamente. Quel BFF chiama poi i servizi interni e restituisce una risposta su misura per le schermate e i vincoli del client.

Un modo semplice per figurarsi il percorso della richiesta:

• Percorso API gateway: Client -> Gateway -> Service(s) -> Response
• Percorso BFF: Client -> BFF (web o mobile) -> Service(s) -> Response

Cambia anche la proprietà. Tipicamente il team piattaforma o infrastruttura possiede il gateway perché impatta ogni team e servizio. Un team di feature spesso possiede un BFF perché si muove con l'interfaccia e il suo ciclo di rilascio.

L'autenticazione spesso scorre così: il client invia un token, lo strato edge (gateway o BFF) lo valida o lo inoltra a un servizio auth, poi passa i dettagli d'identità (user id, ruoli) ai servizi a valle. La differenza sta in dove applichi regole specifiche del client. Con un gateway le policy sono solitamente generiche e coerenti; con un BFF puoi aggiungere shaping specifico per client, per esempio restituire un payload ridotto per mobile o combinare più chiamate in una sola per reti lente.

Quello step di shaping è dove i BFF eccellono, ma significa anche più componenti da distribuire e mantenere coerenti.

Separare in sicurezza endpoint pubblici vs interni

Un endpoint pubblico è qualsiasi route API raggiungibile dalla tua web app, app mobile, partner o terze parti. Trattalo come ostile per impostazione predefinita, perché non controlli la rete su cui viaggia o il codice client che lo chiama.

Un endpoint interno è pensato per il traffico service-to-service dentro il tuo sistema. Può cambiare più velocemente, assumere più contesto ed esporre dati più ricchi, ma non dovrebbe mai essere raggiungibile direttamente da internet pubblico.

Con un API gateway la separazione è spesso fisica e facile da ragionare: solo il gateway è esposto e decide quali route esterne esistono. Tutto ciò che sta dietro rimane privato. Puoi mantenere le API interne espressive, mentre il gateway impone una superficie minore e più sicura.

Con il pattern BFF la separazione è più legata ai confini di prodotto. Ogni client (web, iOS, Android) parla solo al suo BFF, e il BFF parla ai servizi interni. Questo ti permette di nascondere la complessità interna: il BFF può chiamare tre servizi, unire i risultati ed esporre una singola risposta che corrisponde a ciò di cui il client ha realmente bisogno.

La separazione è sicura solo se aggiungi controlli pratici:

• Autorizzazione specifica: ruoli e scope per route, non un unico switch "logged in"
• Rate limit per utente, token e IP sugli endpoint pubblici
• Filtraggio dei payload: restituisci solo ciò che il client necessita, elimina ID interni, info di debug e campi riservati all'admin
• Chiarificare le allowlist: quali endpoint sono pubblici e quali sono solo interni

Esempio: l'app mobile ha uno schermo "I miei ordini". Il BFF può esporre /orders con solo stato e totali dell'ordine, mentre il servizio interno mantiene private le ripartizioni di costo e i flag antifrode.

Versioning: cosa diventa più semplice e cosa più difficile

Il dolore del versioning appare quando web e mobile procedono a velocità diverse. Un team web può rilasciare e rollbackare in ore. Un'app mobile può impiegare giorni o settimane per via delle revisioni sugli store e degli utenti che non aggiornano. Quello è il gap dove la decisione API gateway vs BFF diventa pratica.

Con un API gateway puoi mettere il versioning a un unico punto d'ingresso (per esempio \/v1/...`, `/v2/...``). È facile da spiegare e da instradare. Il rovescio della medaglia è che il gateway può diventare un museo di versioni se molti client e integrazioni partner restano su versioni vecchie. Finirai per supportare forme di dati obsolete più a lungo.

Con un BFF il versioning è spesso "per client". Il BFF mobile può restare su un contratto più vecchio mentre il BFF web avanza, anche se entrambi parlano agli stessi servizi interni. Questo riduce la pressione di mantenere versioni pubbliche in eterno. Il compromesso è più componenti da gestire: ora hai decisioni di versioning multiple da deployare.

Versionare dentro i servizi può funzionare, ma spinge i cambi guidati dai client in profondità nel sistema. Può anche rendere il codice interno più difficile da leggere perché la logica del servizio inizia a ramificare per versione client.

I cambi non-breaking sono i tuoi migliori alleati: aggiungere campi opzionali, nuovi endpoint o accettare input extra. Breaking change includono rinominare un campo, cambiare tipo (stringa -> numero) o rimuovere un endpoint.

La deprecazione funziona meglio quando è pianificata:

• Imposta una data di disattivazione chiara e comunica in anticipo
• Monitora l'uso della vecchia versione (log, metriche) e cerca gli stragglieri
• Rilascia prima gli aggiornamenti client (soprattutto mobile), poi rimuovi il vecchio percorso
• Restituisci un messaggio d'errore chiaro quando la versione vecchia è bloccata

Performance: latenza, dimensione del payload e numero di chiamate

La performance in un setup API gateway vs BFF è principalmente un compromesso: un hop server-side in più nel sistema contro meno hop lenti e inaffidabili dalla rete del client. L'opzione più veloce è spesso quella che riduce il tempo di rete del client, anche se aggiunge un piccolo passaggio server-side.

Un BFF spesso vince quando il client altrimenti farebbe molte chiamate. Invece di far fare a web e mobile cinque endpoint e far cucire i risultati sul dispositivo, il BFF può recuperare lato server ciò che serve e restituire una sola risposta. Questo in genere riduce la latenza totale su mobile perché le reti cellulari aggiungono ritardo a ogni richiesta.

Vantaggi comuni di gateway o BFF in termini di performance:

• Aggregazione: unire dati da più servizi in una singola risposta
• Caching più intelligente: cache al bordo o al BFF per schermate read-heavy
• Payload più piccoli: restituire solo i campi necessari alla schermata
• Meno round trip: ridurre comportamenti chatty lato client
• Compressione e timeout coerenti: imporre default in un punto solo

Ma il pattern può anche penalizzare. Ogni strato aggiunto aggiunge lavoro CPU e più punti di attesa. Se duplichi la stessa logica di aggregazione per web e mobile potresti raddoppiare il lavoro e creare comportamenti incoerenti. L'over-fetching è un'altra perdita comune: un endpoint generico che cerca di soddisfare tutte le schermate può restituire payload grandi che sprecano tempo e banda.

Le realtà mobile rendono questi compromessi più netti. Reti instabili significano retry e timeout, e ogni chiamata extra consuma batteria. I cold start contano: se l'app necessita di molte richieste prima che la prima schermata sia utilizzabile, l'utente lo sente.

Una regola pratica: ottimizza prima per meno richieste client, poi ottimizza il hop aggiunto.

Metodo rapido per giudicare un design

Se una schermata richiede più di 2-3 chiamate sequenziali, considera l'aggregazione. Se le risposte sono grandi e in gran parte inutilizzate, considera di dividere gli endpoint o usare un BFF su misura per client.

Operazioni: deployment, monitoring e scaling

Con API gateway vs BFF la grande domanda operativa è quanti componenti sei disposto a eseguire e supportare. Un gateway spesso diventa infrastruttura condivisa per molti team e client. I BFF sono solitamente servizi piccoli, ma potresti ritrovarti con uno per client (web, iOS, Android, partner), aumentando il carico di release e on-call.

Su testing e rilasci, un gateway può essere più sicuro quando serve principalmente routing, auth e rate limit. I cambiamenti sono centralizzati, quindi un errore può impattare tutti. I BFF riducono il blast radius perché una modifica web viene distribuita solo al BFF web, non anche a quello mobile. Il compromesso è avere più pipeline da mantenere e più versioni in volo.

Per l'osservabilità, devi vedere una singola richiesta utente attraverso i livelli, specialmente quando una chiamata mobile scatena più chiamate backend.

• Usa un correlation ID e passalo attraverso gateway, BFF e i log dei backend
• Cattura trace per individuare dove si consuma tempo (gateway, BFF, servizio a valle)
• Mantieni log strutturati (client, endpoint, codice di stato, latenza, dimensione payload)
• Monitora poche metriche chiave per endpoint: error rate, p95 latency, throughput

Lo scaling appare diverso. Un gateway è un punto di strozzatura condiviso: deve gestire spike e endpoint caldi senza diventare un collo di bottiglia. I BFF ti permettono di scalare per client, utile quando il traffico web sale nelle ore di lavoro mentre il mobile resta stabile.

Negli incidenti, i fallimenti possono "spostarsi" a seconda del pattern. Con un gateway i problemi si vedono spesso come 5xx diffusi o errori di auth. Con i BFF i problemi possono essere isolati a una feature di un client. Prepara runbook chiari su dove guardare prima e mantieni comportamenti di fallback semplici (per esempio, restituire una risposta ridotta invece di andare in timeout).

Come scegliere: un processo decisionale semplice passo dopo passo

Scegliere tra un API gateway e un BFF è meno teoria e più cosa i tuoi client richiedono nella pratica.

Un flusso decisionale pratico

1. Parti dai client, non dai server. Elenca ogni client che supporti (web app, iOS, Android, API partner, admin interno) e annota cosa serve a ogni schermata chiave. Se la stessa vista "Dettagli cliente" richiede campi diversi e schemi di chiamata diversi tra i client, è un segnale forte per shaping specifico per client.

2. Mappa cosa hai oggi. Prendi gli endpoint attuali e segnala cosa è condiviso (operazioni core di dominio come ordini, pagamenti, utenti) versus cosa è modellato per la presentazione (un sommario dashboard, un payload combinato per la schermata "home"). Le parti condivise appartengono al backend core. Le parti shaped per la presentazione spesso vanno meglio in un BFF.

3. Decidi dove mettere shaping e regole. Se ti servono principalmente routing, auth, rate limit, caching e esposizione sicura di endpoint pubblici vs interni, un gateway è il posto naturale. Se hai bisogno di composizione reale (chiamare più servizi, trasformare sei chiamate in una, payload diversi per app), metti quella logica nel codice del BFF così resta testabile e leggibile.

4. Scegli regole di versioning e deprecazione che puoi davvero rispettare. Per esempio: "Nessun breaking change senza nuova versione, e ogni campo deprecato resta 90 giorni." Con un approccio solo gateway potresti versionare la superficie pubblica e tradurre dietro; con i BFF spesso puoi mantenere stabili le API core e versionare solo gli endpoint BFF per client.

5. Pianifica rollout e misura. Prima di cambiare qualsiasi cosa cattura metriche baseline: p95 latency, numero di chiamate per schermata, dimensione dei payload e error rate. Rolla su una piccola percentuale, confronta prima/dopo e poi amplia.

Un esempio semplice: se la tua app mobile rilascia mensilmente ma il portale web rilascia giornalmente, un piccolo BFF mobile può proteggere l'app da cambi frequenti del backend mentre il client web continua a muoversi velocemente.

Esempio: portale web + app mobile con velocità di rilascio diverse

Immagina un'azienda con un portale clienti web e un'app per gli operatori sul campo. Entrambi hanno bisogno degli stessi dati core: clienti, lavori, fatture e messaggi. Il portale cambia settimanalmente. L'app mobile aggiorna più lentamente per via della revisione sugli store e deve funzionare con segnale debole.

Il problema emerge in fretta. Gli utenti mobile vogliono risposte compatte, meno chiamate e flussi che supportino il lavoro offline (per esempio, scaricare i lavori del giorno e poi sincronizzare le modifiche). Il portale web può fare più chiamate e caricare schermate ricche perché è sempre online e più facile da aggiornare.

Opzione A: gateway API davanti a servizi stabili

La scelta gateway-first mantiene i servizi backend sostanzialmente invariati. Il gateway gestisce autenticazione, routing e piccole modifiche come header, rate limit e semplice mapping di campi.

Il versioning resta soprattutto al livello delle API dei servizi. Questo può essere positivo: meno componenti. Ma significa anche che i cambi specifici per mobile spesso ti portano a versioni ampie come /v2 perché gli endpoint sottostanti sono condivisi.

L'esposizione degli endpoint è più chiara se tratti il gateway come l'unica porta pubblica. Gli endpoint interni rimangono dietro, ma devi essere rigoroso su cosa il gateway può raggiungere e cosa pubblica.

Opzione B: un BFF mobile che parla "mobile"

Con un BFF mobile, l'app mobile parla a endpoint progettati per schermate mobile e flussi di sync. Il BFF può aggregare dati (dettagli lavoro + cliente + ultimo messaggio), tagliare campi e restituire un payload che corrisponde alle esigenze dell'app.

Cosa cambia:

• Il versioning diventa più semplice per client: puoi versionare il BFF mobile senza costringere il portale web a muoversi
• La performance spesso migliora per mobile: meno round trip e risposte più piccole
• La separazione pubblico vs interno diventa più netta: il BFF è pubblico, ma chiama servizi interni che non devono mai essere esposti

Errori comuni e trappole da evitare

La trappola più grande è trasformare il gateway in un mini-backend. I gateway vanno bene per routing, auth, rate limit e shaping semplice. Se ci infili regole di business, ottieni logica nascosta difficile da testare, difficile da debug e facile da rompere con una modifica di config.

I BFF possono sbagliare nell'altro senso: i team creano un BFF per ogni schermata o feature e la manutenzione esplode. Un BFF dovrebbe di solito mappare a un tipo di client (web, iOS, Android) o a una chiara area di prodotto, non ad ogni vista UI. Altrimenti duplicherai le stesse regole in dieci posti e il versioning diventerà un lavoro a tempo pieno.

Gli errori di versioning spesso vengono dagli estremi. Versionare tutto subito congela l'API troppo presto e mantiene varianti vecchie per sempre. Non versionare mai porta a breaking change non intenzionali. Una regola semplice: non versionare per piccoli cambi additivi; versiona quando rimuovi qualcosa o cambi significato.

Pubblico vs interno è dove i team si fanno più male. Esporre servizi interni direttamente su internet (anche "temporaneamente") trasforma ogni cambiamento interno in un possibile outage o incidente di sicurezza. Mantieni un confine chiaro: solo il gateway o il BFF devono essere pubblici, i servizi interni restino privati.

I problemi di performance sono spesso auto-inflitti: payload sovradimensionati, troppi round trip e nessun budget per la latenza. Per esempio, un'app mobile potrebbe avere bisogno solo di stato e totali d'ordine, ma ricevere l'oggetto ordine completo con ogni riga e campi di audit, rendendo ogni richiesta lenta su rete cellulare.

Segnali di avvertimento da monitorare:

• Config del gateway che fa riferimento a concetti di business come "eleggibilità rimborso" o "regole VIP"
• I BFF crescono più velocemente dei client che dovrebbero servire
• Non riesci a spiegare la strategia di versioning in una frase
• Endpoint di servizio interni sono raggiungibili da internet pubblico
• Le risposte continuano a crescere perché "potrebbe servire più avanti"

Checklist rapida e prossimi passi

Se sei bloccato sulla decisione API gateway vs BFF, concentrati su cosa si romperebbe prima nella realtà: rilasci, payload e confini di sicurezza.

Checklist rapida

Se rispondi "no" a diverse di queste, il tuo setup attuale probabilmente ti danneggerà man mano che i client crescono:

• Puoi cambiare un servizio backend senza costringere ogni client ad aggiornare la stessa settimana?
• Esiste un confine chiaro tra endpoint pubblici (sicuri per internet) e interni (solo sistemi trusted)?
• Web e mobile ricevono solo ciò di cui hanno bisogno (non un mega-response "kitchen sink")?
• Puoi rilasciare gradualmente (prima una percentuale ridotta) e vedere errori, latenza e traffico anomalo rapidamente?
• Sai chi possiede il contratto per ogni endpoint e chi approva breaking change?

Prossimi passi

Trasforma le risposte in un piano. L'obiettivo non è l'architettura perfetta, ma meno sorprese quando rilasci.

Scrivi il contratto API in linguaggio semplice (input, output, codici di errore, cosa è permesso cambiare). Scegli un modello di ownership: chi possiede i bisogni client (web/mobile) e chi possiede i servizi di dominio core. Decidi dove vivere il versioning (per client o centralmente) e stabilisci una regola di deprecazione che seguirai.

Aggiungi monitoring di base prima di grandi refactor: request rate, p95 latency, error rate e gli endpoint con payload più grandi. Prototipa prima i flussi client più rischiosi.

Se stai costruendo con AppMaster (appmaster.io), un approccio pratico è mantenere la logica core e i modelli dati nel backend generato, quindi aggiungere un gateway o un layer BFF sottile solo dove un client necessita davvero di shaping o isolamento dei rilasci.

Se la checklist è difficile da completare, prendilo come segnale: semplifica il contratto e stringi il confine pubblico vs interno prima di aggiungere altri endpoint.