BFF: backends for frontends

Soms zie je door de bomen het bos niet meer. Een team werkt aan de iOS app, nog een team aan de Android app, een klein team aan de web app en nog een team neemt de backend API voor rekening. Sjoerd vertelt je in deze blog hoe je daarmee om kunt gaan.

11 oktober 2022   |   Blog   |   Door: Sjoerd Santema, Solution Architect bij Conclusion Enablement

Deel

Frontend ontwikkeling voor een mobiele applicatie

Stel, je hebt een zeer succesvolle B2C dienst. Jaren geleden ben je begonnen met een webapplicatie. Maar als snel kreeg je door dat een mobiele app beter aansluit op wat je je klanten te bieden hebt en wat ze verwachten. Dus heb je een iOS app laten bouwen. Natuurlijk liet een Android app niet lang op zich wachten. Inmiddels is je dienst zo succesvol dat je een klein leger aan developers hebt aangenomen. Een team werkt aan de iOS app, nog een team aan de Android app, een klein team aan de web app en nog een team neemt de backend API voor rekening.

Al snel wordt de backend API een knelpunt. Je komt erachter dat de teams die de mobiele app ontwikkelen afhankelijk zijn van het team dat de backend API ontwikkelt. Ook stellen de teams die de mobiele app ontwikkelen andere eisen aan de backend API dan het team dat de web app ontwikkelt.

Dat is niet zo gek want gebruikers van de mobiele app hebben een minder stabiele internetverbinding en de user interface van de mobiele app is een stuk lichter dan die van de web app. Ook lopen zowel het iOS team als het Android team er tegenaan dat ze afhankelijk zijn van elkaars planning, die van het web app team en vooral ook die van het backend team.

 Dit kan beter!

Illustratie A: een backend voor alle frontends

Ik presenteer u het Backend for Frontend (BFF) patroon

Het patroon lijkt heel simpel: geef elke frontend een eigen backend. Je knipt de generieke backend API op en geeft de ontwikkeling van deze BFF aan hetzelfde team dat aan de frontend werkt. Door de BFF en de frontend in een team onder te brengen, elimineer je de afhankelijkheden tussen de teams.

Illustratie B: een BFF per frontend

Om over na te denken

Er zijn wel een aantal gevolgen waar je rekening mee moet houden. De BFF’s zullen een overlap hebben in functionaliteit en dus ook in code. Dat is op zichzelf niet erg, maar het is wel handig op gezette tijden te evalueren of ontwikkelingen in de BFF’s gedeeld kunnen worden tussen de teams. Want waarom zou je meerdere keren proberen het wiel uit te vinden als een van de teams een bepaalde functionaliteit of technologie al succesvol toegepast heeft? Je zal dit in een proces moeten borgen.

Ook op de kosten kan het BFF-patroon invloed hebben. Je hebt ineens met meerdere backends te maken die los van elkaar gedeployed worden. Iets om over na te denken.

Andere voordelen

Als je met één generieke backend API werkt, heb je te maken met meerdere frontends. Deze backend krijgt alle calls van de frontends te verstouwen. Dit kan een impact hebben op de performance van de backend. Door met losse BFF’s te werken, verspreid je de load over meerdere backends.

Ook maak je het door deze scheiding aan te brengen inzichtelijk wat elke BFF kost en hoeveel tijd er aan de ontwikkeling ervan wordt besteed. Maar er is meer. Zo kan het zijn dat je een bepaalde iOS of Android feature wil ondersteunen en de BFF biedt je alle ruimte dit uit te rollen zonder afhankelijk te zijn van een backend team of de andere frontends.

Downstream services

Meestal bevraagt de BFF downstream services. Hoe je deze organiseert ligt wel in het verlengde van het BFF-patroon, maar is er niet direct een onderdeel van. Toch neem ik je in de onderstaande illustratie mee in hoe je deze downstream services kan ontwerpen.

Illustratie C: BFF’s en losse services, verdeeld over vier teams

De BFF’s zullen voor een deel dezelfde data nodig hebben en dezelfde downstream services bevragen. Soms is het handig een deel van die logica onder te brengen in losstaande services. Deze losstaande services nemen de afhandeling en verwerking van verzoeken naar downstream services voor hun rekening.

Door deze logica buiten de BFF’s onder te brengen in services, voorkom je dat je deze logica in alle BFF’s moet dupliceren. Tegelijkertijd geef je de BFF’s wel de mogelijkheid om zelf te bepalen hoe de data opgehaald wordt en in welke volgorde. Ook kan je in de BFF bepalen hoe ermee om te gaan als een van de services niet beschikbaar is of traag reageert.

Hetzelfde geldt voor de losstaande services. In deze services kan je bepalen wat er moet gebeuren als downstream services niet werken en/of de data uit andere bronnen opgehaald kan worden. Je verdeeld daarmee de verantwoordelijkheden en logica over losse services en BFF’s in plaats van in een centrale backend API. Divide et impera!

Conclusie

Het BFF-patroon zorgt ervoor dat je de logica en verantwoordelijkheden van een generieke backend API kan verdelen over losse BFF’s en services. De BFF’s (en services) kan je onderbrengen in losse teams of combineren met de frontend teams. Zo elimineer je afhankelijkheden tussen teams en kunnen de frontend teams zich richten op het leveren van de beste gebruikerservaring voor de betreffende frontend.

De downstream services kan je per BFF bevragen of je kan deze via losstaande services aan de BFF’s beschikbaar stellen. Zoals met alles hebt elk voordeel z’n nadeel [sic] en staat een patroon nooit op zichzelf.

Terug naar ons nieuwsoverzichtOntdek onze vacaturesBekijk onze cases

Wil je hier meer over weten?

Neem dan contact met me op. Ik vertel je graag meer!

Sjoerd Santema, Solution Architect bij Conclusion Enablement

Sjoerd Santema

Solution Architect
sjoerd.santema@conclusion.nl