API-gateway vs BFF voor web- en mobiele clients: afwegingen

Het probleem: één backend, veel clients, veranderende behoeften

Een veelvoorkomend begin is simpel: één backend biedt een set endpoints, en zowel de webapp als de mobiele app roept die aan. Het voelt efficiënt omdat er één plek is om features toe te voegen, bugs te fixen en regels af te dwingen.

Dan slaat de realiteit toe. De web-UI heeft vaak dichte schermen, filters, exports en admin-acties nodig. Mobiel heeft meestal minder velden nodig, snellere schermen, offline-vriendelijke flows en voorzichtigheid met batterij- en datagebruik. Zelfs wanneer de feature "hetzelfde" is, is de beste API-vorm voor elke client zelden identiek.

In de loop van de tijd driften endpoints uiteen. Een webteam voegt extra velden toe voor een nieuwe tabelweergave. Mobiel vraagt om zware payloads te verwijderen en meerdere calls te combineren. Iemand voegt een parameter "alleen voor iOS" toe. Weer een ander hergebruikt een interne admin-endpoint in de publieke app omdat het "er al was". Wat begon als één schone API wordt een verzameling compromissen.

De risico's verschijnen snel:

• Brekende veranderingen wanneer de ene client sneller uitrolt dan de andere
• Langzamere apps door grote payloads of te veel rondes
• Complexere backendcode omdat elk endpoint voor elke client probeert te dienen
• Onbedoelde datalekken wanneer interne velden of acties in publieke APIs belanden
• Pijnlijke versiebeheer omdat "kleine wijzigingen" voor oudere clients niet klein zijn

Dit is de kernspanning achter de API-gateway vs BFF-discussie. Je wilt stabiele publieke API's waar mobiel en web op kunnen vertrouwen, terwijl elke client ruimte krijgt om in eigen tempo te evolueren.

API-gateway en BFF: wat ze zijn (en niet zijn)

Een API-gateway is de voordeur voor je API's. Clients roepen de gateway aan en die routet verzoeken naar de juiste backendservice. Vaak behandelt de gateway gedeelde zorgen die je niet overal wilt herhalen, zoals authenticatiechecks, rate limits, request logging en basis request-shaping.

Een backend-for-frontend (BFF) is een kleine backend gebouwd voor één specifieke client of groep clients, zoals "web" en "mobile". De client roept zijn BFF aan, en de BFF roept de onderliggende services aan. Het sleutelidee is focus: de BFF mag de taal van de client spreken (schermen, flows en payloads), zelfs als de core services generieker blijven.

Wat deze patronen niet zijn: ze vervangen geen goede domain services of een schoon datamodel. Je core services, databases en businessregels moeten de bron van waarheid blijven. Een gateway of BFF mag niet veranderen in een grote kluwen van businesslogic die langzaam je echte backend wordt.

Een eenvoudige manier om ze te onderscheiden:

• Gateway: één ingangspunt, gedeelde zorgen, routing en bescherming
• BFF: client-specifieke API's die clientwerk verminderen en interne complexiteit verbergen

Je kunt ze ook combineren. Een gebruikelijke opzet is een gateway als publiek edge, met daarachter aparte BFFs voor web en mobiel. De gateway handelt buitenste security en trafficregels af, terwijl elke BFF endpoints en responses vormgeeft voor zijn client.

Hoe het request-pad verandert in elk patroon

Het grootste verschil tussen een API-gateway en een BFF is waar je de "voordeur"-logica plaatst: routing, authenticatiechecks en response-shaping.

Bij een API-gateway praat de client meestal met één gedeeld toegangspunt. De gateway forwardt requests naar interne services en doet vaak basisdingen zoals tokenvalidatie, rate limiting en routing op basis van pad.

Bij een BFF roept elk clienttype (web, iOS, Android) een backend aan die specifiek voor hen is gebouwd. Die BFF roept vervolgens interne services aan en geeft een response terug die is afgestemd op de schermen en beperkingen van die client.

Een eenvoudige weergave van het request-pad:

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

Eigenaarschap verschuift vaak ook. Een platform- of infrastructuurteam bezit doorgaans de gateway omdat die ieder team en elke service raakt. Een featureteam bezit vaak een BFF omdat die meebeweegt met de UI en de releasecyclus.

Authenticatie loopt vaak zo: de client stuurt een token, de edge layer (gateway of BFF) valideert het of stuurt het naar een auth-service, en geeft vervolgens identiteitgegevens (user id, rollen) door aan downstream services. Het verschil is waar je clientregels toepast. Bij een gateway zijn policies meestal generiek en consistent. Bij een BFF kun je client-specifieke shaping toevoegen, zoals een kleinere payload voor mobiel of het combineren van meerdere servicecalls in één response voor trage netwerken.

Die shapingstap is waar BFFs uitblinken, maar het betekent ook meer bewegende delen om te deployen en consistent te houden.

Publieke vs interne endpoints veilig scheiden

Een publiek endpoint is elke API-route die je webapp, mobiele app, partners of derden kunnen bereiken. Behandel het standaard als hostile, omdat je het netwerk of de clientcode die het aanroept niet controleert.

Een intern endpoint is bedoeld voor service-to-service verkeer binnen je systeem. Het kan sneller veranderen, meer context aannemen en rijkere data blootstellen, maar het mag nooit rechtstreeks vanaf het publieke internet bereikbaar zijn.

Met een API-gateway is de scheiding vaak fysiek en makkelijk te beredeneren: alleen de gateway is blootgesteld en die beslist welke externe routes bestaan. Alles daarachter blijft privé. Je kunt interne service-API's expressief houden, terwijl de gateway een kleinere, veiligere oppervlakte afdwingt.

Met het backend-for-frontend-patroon is de split meer over productgrenzen. Elke client (web, iOS, Android) praat alleen met zijn BFF, en de BFF praat met interne services. Dat laat je interne complexiteit verbergen: de BFF kan drie services aanroepen, resultaten samenvoegen en één simpele response exposen die past bij wat de client echt nodig heeft.

De scheiding is alleen veilig als je praktische controles toevoegt:

• Specifieke autorisatie: rollen en scopes per route, niet één "ingelogd"-schakelaar
• Rate limits per gebruiker, token en IP voor publieke endpoints
• Payload-filtering: retourneer alleen wat de client nodig heeft, verwijder interne IDs, debug-info en admin-only velden
• Duidelijke allowlists: welke endpoints publiek zijn, welke alleen intern

Voorbeeld: een mobiele app heeft een "Mijn bestellingen"-scherm nodig. De BFF kan /orders exposen met alleen orderstatus en totalen, terwijl de interne orderservice gedetailleerde kostenspecificaties en fraude-flags privé houdt.

Versioning: wat wordt makkelijker en wat moeilijker

Versioning-pijn verschijnt meestal wanneer web en mobiel in verschillende snelheden bewegen. Een webteam kan binnen uren uitrollen en terugdraaien. Een mobiele app kan dagen of weken duren door app store-review en gebruikers die niet updaten. Dat gat is waar de API-gateway vs BFF-beslissing praktisch wordt.

Met een API-gateway kun je versioning op één voordeur zetten (bijv. /v1/..., /v2/...). Dat is makkelijk uit te leggen en te routeren. Het nadeel is dat de gateway kan veranderen in een versie-museum als veel clients en partnerintegraties aan oude versies vasthouden. Je houdt zo lang verschillende datavormen in stand.

Met een BFF is versioning vaak "per client". De mobiele BFF kan op een ouder contract blijven terwijl de web BFF sneller gaat, zelfs als beide dezelfde interne services aanspreken. Dat vermindert meestal de druk om publieke versies eeuwig te ondersteunen. De afweging is meer bewegende delen: je hebt nu meerdere versie-beslissingen te beheren en te deployen.

Versioning binnen services kan ook werken, maar het duwt clientgedreven veranderingen diep in je systeem. Het kan interne code ook moeilijker leesbaar maken omdat service-logica gaat takken op clientversies.

Niet-brekende wijzigingen zijn je beste vriend: optionele velden toevoegen, nieuwe endpoints toevoegen of extra inputvelden accepteren. Brekende wijzigingen zijn bijvoorbeeld het hernoemen van een veld, het veranderen van een type (string naar number) of het verwijderen van een endpoint.

Deprecatie werkt het best wanneer het gepland is:

• Stel een duidelijke sunset-datum in en communiceer die vroeg
• Volg gebruik van de oude versie (logs, metrics) en zoek naar achterblijvers
• Rol client-updates eerst uit (vooral mobiel), verwijder daarna het oude pad
• Geef een duidelijke foutmelding wanneer een oude versie uiteindelijk geblokkeerd wordt

Performance: latency, payloadgrootte en aantal calls

Performance in een API-gateway vs BFF-opzet is meestal een afweging: één extra hop binnen je systeem tegenover minder hops over het netwerk vanaf de client. De snelste optie is vaak degene die trage, onbetrouwbare clientnetwerktijd vermindert, zelfs als het een kleine server-side stap toevoegt.

Een BFF wint vaak wanneer de client anders veel calls zou doen. In plaats van dat web en mobiel vijf endpoints aanroepen en resultaten op het apparaat samenvoegen, kan de BFF server-side wat nodig is ophalen en één response teruggeven. Dat verkort meestal de totale latency op mobiel omdat mobiele netwerken extra vertraging geven bij elke aanvraag.

Veelvoorkomende performanceverbeteringen door een gateway of BFF:

• Aggregatie: combineer data van meerdere services in één response
• Slimmere caching: cache aan de edge of bij de BFF voor read-heavy schermen
• Kleinere payloads: retourneer alleen velden die het scherm nodig heeft
• Minder roundtrips: reduceer chatty gedrag van clients
• Consistente compressie en timeouts: dwing defaults af op één plek

Maar het patroon kan ook schaden. Elke extra laag voegt CPU-werk en meer wachttijd toe. Als je dezelfde aggregatielogica dupliceert voor web en mobiel, verdubbel je mogelijk het werk en creëer je inconsistent gedrag. Over-fetching is een andere veelvoorkomende verliespost: een generiek endpoint dat probeert elk scherm te bedienen, kan grote payloads teruggeven die tijd en bandbreedte verspillen.

Mobiele realiteiten maken deze afwegingen scherper. Flinke netwerken betekenen retries en timeouts zijn normaal, en elke extra call kost batterij. Cold starts tellen ook: als de app meerdere verzoeken nodig heeft voordat het eerste scherm bruikbaar is, merken gebruikers het.

Een praktische regel: optimaliseer eerst voor minder client-requests, optimaliseer daarna de extra hop.

Snelweg om een ontwerp te beoordelen

Als een scherm meer dan 2-3 opeenvolgende calls nodig heeft, overweeg aggregatie. Als responses groot zijn en grotendeels ongebruikt, overweeg endpoints te splitsen of een client-gerichte BFF te gebruiken.

Operaties: deployment, monitoring en scaling

Bij API-gateway vs BFF is de grote operationele vraag hoeveel bewegende delen je wilt draaien en ondersteunen. Een gateway wordt vaak gedeelde infrastructuur voor veel teams en clients. BFFs zijn meestal kleinere services, maar je kunt er één per client krijgen (web, iOS, Android, partner), wat release- en on-call last vergroot.

Qua testen en releases kan een gateway veiliger zijn wanneer je voornamelijk routing, auth en rate limits nodig hebt. Wijzigingen zijn gecentraliseerd, dus één fout kan iedereen raken. BFFs verkleinen de blast radius omdat een web-only wijziging naar de web BFF wordt uitgerold, niet naar de mobiele. De afweging is meer pipelines om te onderhouden en meer versies tegelijkertijd.

Voor observability moet je één gebruikersrequest over lagen heen kunnen zien, vooral wanneer één mobiele call meerdere backend-calls triggert.

• Gebruik een correlation ID en geef die door in gateway, BFF en backend logs
• Leg traces vast zodat je kunt zien waar tijd wordt besteed (gateway, BFF, downstream service)
• Houd gestructureerde logs bij (client, endpoint, statuscode, latency, payloadgrootte)
• Volg een paar kernmetrics per endpoint: error rate, p95 latency, throughput

Scaling ziet er ook anders uit. Een gateway is een gedeelde choke point: die moet pieken en hot endpoints aan kunnen zonder zelf de bottleneck te worden. BFFs laten je per client schalen, wat helpt als webverkeer tijdens kantooruren piekt terwijl mobiel stabiel blijft.

In incidenten kunnen failures "verhuizen" afhankelijk van het patroon. Met een gateway verschijnen problemen vaak als wijdverspreide 5xx- of auth-fouten. Met BFFs kunnen issues geïsoleerd zijn tot één client-feature. Maak runbooks duidelijk over waar eerst te kijken en houd fallback-gedrag simpel (bijv. retourneer een gereduceerde response in plaats van te time-outen).

Hoe te kiezen: een eenvoudige stapsgewijze beslisboom

Kiezen tussen een API-gateway en een BFF gaat minder over theorie en meer over wat je clients dagelijks nodig hebben.

Een praktische beslisflow

1. Begin bij je clients, niet je servers. Schrijf elke client op die je ondersteunt (webapp, iOS, Android, partner-API, interne admin) en noteer wat elk belangrijk scherm nodig heeft. Als hetzelfde "Klantdetails"-scherm verschillende velden en callpatronen nodig heeft per client, is dat een sterk signaal voor client-specifieke shaping.

2. Kaart je huidige situatie. Neem je endpoints en markeer wat gedeeld is (core domain-operaties zoals orders, betalingen, users) versus wat presentatiegevormd is (dashboard-samenvatting, gecombineerde "home screen" payload). Gedeelde stukken horen in de core backend. Presentatiegevormde stukken passen meestal beter in een BFF.

3. Bepaal waar shaping en regels moeten leven. Als je vooral routing, auth, rate limits, caching en veilige blootstelling van publieke vs interne endpoints nodig hebt, is een gateway de natuurlijke plek. Als je echte compositie nodig hebt (meerdere services aanroepen, zes calls in één veranderen, verschillende payloads per app), zet die logica in BFF-code zodat het testbaar en leesbaar blijft.

4. Kies een versioning- en deprecatieregel die je ook echt volgt. Bijvoorbeeld: "Geen breaking changes zonder nieuwe versie, en elk gedepricieerd veld blijft 90 dagen staan." Met alleen een gateway kun je de publieke laag versioneren en vertalen erachter. Met BFFs kun je vaak de core APIs stabiel houden en alleen de BFF-endpoints per client versionen.

5. Plan rollout en meet. Leg basismetingen vast voordat je iets verandert: p95 latency, aantal calls per scherm, payloadgroottes en error rates. Rol uit naar een klein percentage eerst, vergelijk voor en na, en breid dan uit.

Een simpel voorbeeld: als je mobiele app maandelijks releaset maar je webportaal dagelijks, kan een kleine mobiele BFF de app beschermen tegen frequente backendveranderingen terwijl de webclient snel blijft bewegen.

Voorbeeld: webportal + mobiele app met verschillende release-snelheden

Stel je een bedrijf voor met een klantenportal op web en een field-app op mobiel. Beide hebben dezelfde coredata nodig: klanten, jobs, facturen en berichten. De portal verandert wekelijks. De mobiele app updatet langzamer vanwege app store-review en moet ook werken bij zwak signaal.

De pijn verschijnt snel. Mobiele gebruikers willen compacte responses, minder calls en flows die offline werken (bijv. download de taken van vandaag één keer en sync wijzigingen later). De webportal maakt meer calls en laadt rijkere schermen omdat die altijd online is en makkelijker te updaten.

Optie A: een API-gateway voor stabiele services

De gateway-first keuze houdt je backendservices grotendeels ongewijzigd. De gateway handelt authenticatie, routing en kleine aanpassingen zoals headers, rate limits en eenvoudige veldmapping. Versioning blijft grotendeels op service-API-niveau. Dat kan goed zijn: minder bewegende delen. Maar het betekent ook dat mobiel-specifieke veranderingen je vaak naar brede versies duwen zoals /v2 omdat de onderliggende endpoints gedeeld zijn.

Endpoint-exposure is duidelijker als je de gateway als enige publieke deur ziet. Interne endpoints blijven erachter, maar je moet streng zijn over wat de gateway kan bereiken en wat hij publiceert.

Optie B: een mobiele BFF die "mobile spreekt"

Met een mobiele BFF praat de mobiele app met endpoints die ontworpen zijn voor mobiele schermen en sync-flows. De BFF kan data aggregaten (jobdetails + klant + laatste bericht), velden trimmen en één payload teruggeven die past bij de app.

Wat verandert:

• Versioning wordt per client eenvoudiger: je kunt de mobiele BFF versionen zonder de webportal te dwingen mee te gaan
• Performance verbetert vaak voor mobiel: minder roundtrips en kleinere responses
• Publieke vs interne scheiding wordt scherper: de BFF is publiek, maar roept interne services aan die nooit publiek hoeven te zijn

Veelvoorkomende fouten en valkuilen om te vermijden

De grootste valkuil is de gateway veranderen in een mini-backend. Gateways zijn geweldig in routing, auth, rate limits en eenvoudige request-shaping. Als je ze volstopt met businessregels, ontstaat verborgen logica die moeilijk te testen en te debuggen is en makkelijk kapotgaat door een configwijziging.

BFFs kunnen de andere kant op fout gaan: teams maken één BFF per scherm of per feature en het onderhoud explodeert. Een BFF zou meestal moeten corresponderen met een clienttype (web, iOS, Android) of een duidelijk productgebied, niet elke UI-view. Anders dupliceer je regels op tien plekken en wordt versiebeheer een fulltime taak.

Versioning-fouten komen vaak door extremen. Als je vanaf dag één alles versioneert, vries je je API te vroeg in en houd je oude varianten eeuwig in stand. Als je nooit versieert, breng je per ongeluk breaking changes uit. Een simpele regel werkt goed: versieer niet voor kleine additionele wijzigingen, maar maak een nieuwe versie wanneer je iets verwijdert of de betekenis verandert.

Publieke vs interne endpoints is waar teams vaak pijn ervaren. Interne services tijdelijk direct naar internet blootstellen maakt elke interne wijziging een potentiële outage of security-incident. Houd een duidelijke grens: alleen de gateway of BFF is publiek, en interne services blijven privé.

Performance-problemen zijn meestal zelf veroorzaakt: te grote payloads, te veel roundtrips en geen latencybudget. Bijvoorbeeld: een mobiele app heeft misschien alleen orderstatus en totalen nodig, maar krijgt het volledige orderobject met iedere regel en auditvelden, waardoor elk verzoek traag is op mobiel.

Waarschuwingssignalen om op te letten:

• Gateway-configs refereren aan businessconcepten zoals "refund eligibility" of "VIP rules"
• BFFs vermenigvuldigen sneller dan de clients die ze bedienen
• Je kunt je API-versioningstrategie niet in één zin uitleggen
• Interne service-endpoints zijn bereikbaar vanaf het publieke internet
• Responses blijven groeien omdat "het later misschien handig is"

Snelle checklist en vervolgstappen

Als je vastloopt in de API-gateway vs BFF-beslissing, focus op wat er in de praktijk als eerste zal breken: releases, payloads en security-grenzen.

Snelle checklist

Als je op meerdere van deze "nee" antwoordt, zal je huidige opzet waarschijnlijk problemen geven naarmate je clients groeien:

• Kun je één backendservice veranderen zonder alle clients dezelfde week te dwingen te updaten?
• Is er een duidelijke grens tussen publieke endpoints (veilig voor internet) en interne endpoints (alleen voor vertrouwde systemen)?
• Krijgen web en mobiel alleen wat ze nodig hebben (niet een grote "alles-in-één"-response)?
• Kun je veranderingen geleidelijk uitrollen (eerste klein percentage) en snel fouten, latency en ongebruikelijk verkeer zien?
• Weet je wie het contract voor elk endpoint bezit en wie brekende wijzigingen goedkeurt?

Vervolgstappen

Zet de antwoorden om in een plan. Het doel is geen perfecte architectuur, maar minder verrassingen bij uitrol.

Schrijf je API-contract in gewone taal (inputs, outputs, foutcodes, wat mag veranderen). Kies een eigenaarsmodel: wie bezit clientbehoeften (web/mobiel) en wie bezit core domainservices. Bepaal waar versioning leeft (per client of centraal) en stel een deprecatieregel vast die je volgt.

Voeg basismonitoring toe vóór grote refactors: request-rate, p95 latency, error rate en de top-endpoints op payloadgrootte. Prototypeer de risicovolle clientflows eerst.

Als je bouwt met AppMaster (appmaster.io), is een praktische aanpak om core businesslogica en datamodellen in de gegenereerde backend te houden en alleen een dunne gateway- of BFF-laag toe te voegen waar een client echt andere payloads of release-isolatie nodig heeft.

Als de checklist moeilijk te beantwoorden is, zie dat als een signaal om het contract te vereenvoudigen en de publieke vs interne scheiding aan te scherpen vóór je meer endpoints toevoegt.