Waarom we bij Netvlies volgens de API First approach werken

De API First approach stelt developers in staat om API’s te bouwen die makkelijk ontwikkeld en onderhouden kunnen worden voor alle soorten apparaten, platformen en besturingssystemen. Het heeft een heleboel voordelen voor de ontwikkeling, schaalbaarheid en toekomstbestendigheid van bijvoorbeeld een webapplicatie. Daarnaast biedt het een betere development experience dan traditioneel applicatie ontwerp. In dit blog ga ik dieper in op de voordelen van API First, leg ik uit waarom we bij Netvlies volgens deze aanpak zijn gaan werken en hoe we dit toepassen in projecten.

De API First approach is een andere manier van denken en werken. De aanpak dwingt developers om te bedenken hoe de ‘business problemen’ van de klant opgelost moeten worden, zonder direct te focussen op techniek. De API die op basis hiervan wordt opgezet, is daardoor consistenter en makkelijker te hergebruiken dan traditioneel webapplicatie ontwerp. Hiervoor leggen frontenders en backenders samen vast hoe de API zich moet gedragen door te denken in functionaliteiten in plaats van techniek en design. Met het idee dat er voor allerlei type devices, platformen en besturingssystemen een interface te bouwen is die met dezelfde API communiceert.

Hoe zetten wij API First in binnen onze projecten?

Onze projecten beginnen doorgaans met een Design Sprint. De output hiervan is een gevalideerd prototype met wireframes. Backend en frontend developers gaan rond de tafel om – op basis van het atomic design principe – te bepalen uit welke componenten het product bestaat, hoe die aan elkaar gerelateerd zijn, wat de hiërarchie van de componenten is en hoe functionaliteiten gerelateerd zijn aan het model en de data. Dit noemen we ook wel ‘component poker’.

Vervolgens stellen we, op basis van de componenten uit de component poker, samen het API schema op. Dit beschrijft welke data moet worden opgehaald, met welke API calls dat gebeurd, hoe data bewerkt gaat worden en welke metadata meegestuurd wordt. Het is de lijm tussen de frontend componenten en backend techniek. 

De volgende stap is het technisch bouwen van de API waarbij we zorgen dat alle endpoints getest zijn. Daarnaast gebruiken we unit en integration tests om onafhankelijke delen van de applicatie te testen. Als backender schrijf ik geen testen voor frontend of UX. Elke discipline test zijn eigen code. Ik test dus vooral business logica vanuit verschillende gebruikersrollen, terwijl een frontender meer focus zal leggen op het testen van de interface en de componenten waaruit deze bestaat.

API First en Scrum

Nu de API staat, kunnen we het product gaan bouwen. Dat doen we bij Netvlies al sinds 2012 volgens de projectmethodiek Scrum. De API First aanpak sluit goed aan op deze projectmethodiek, waarbij je in korte doorlooptijd – 2 a 3 weken – een werkend (deel)product oplevert. Doordat een API schema is opgesteld, hoeven disciplines niet op elkaar te wachten bij het ontwikkelen van features. De frontender weet hoe een response eruit gaat zien en kan daarom zonder werkende API werken, bijvoorbeeld door een stub te gebruiken. Hierdoor hoeven developers minder op elkaar te wachten en kan efficiënter met de beschikbare tijd worden omgegaan. 

Welke voordelen heeft API First voor developers?

De voordelen van API First hebben voor ons de doorslag gegeven om de aanpak te integreren in onze dagelijkse manier van werken. Maar wat zijn die voordelen eigenlijk?

Onafhankelijk werken en testen

API First zorgt voor separation of concerns. Waardoor backend zich enkel bezig hoeft te houden met backend gerelateerde zaken en andersom. Dat zorgt voor meer focus en minder discussies. Door het onafhankelijke schema zijn gebruikte technieken niet afhankelijk van elkaar. De API en de frontend zijn twee losse producten. Zolang het API schema hetzelfde blijft, is de frontend helemaal onafhankelijk van de backend op te zetten en kun je aanpassingen in de backend doorvoeren zonder dat dit gevolgen heeft voor de frontend. Je werkt onafhankelijk van elkaar en hoeft om verder te kunnen niet te wachten tot de andere discipline bepaalde zaken heeft gebouwd.

Ook tests kunnen onafhankelijk worden uitgevoerd. Dit maakt het schrijven en uitvoeren hiervan een stuk eenvoudiger. Componenten en de interactiviteit worden voornamelijk op de frontend getest en de business logica, rollen en rechten op de backend. Als je een request naar de backend API stuurt, test je of de response is wat je zou verwachten. Hoe dit wordt weergegeven in de frontend is voor de backend test niet relevant. Voor een frontender is het belangrijk om te testen hoe de UI/UX is, bijvoorbeeld door visuele test te schrijven of door componenten los van elkaar te testen door middel van unit tests. 

Een geschematische weergave van de gescheidde fronend en backend bij API First.

Bovenstaande afbeelding geeft de verandering in werkzaamheden goed weer. De middelste kolom laat ouderwetst webapplicatie ontwerp zien. De rechter kolom geeft onze nieuwe werkwijze weer, waarbij je een duidelijke verschuiving van bepaalde taken van backend naar frontend ziet. Backenders houden zich vooral bezig met data en business logica en niet met hoe de interactiviteit eruit moet zien.

Gemeenschappelijke taal

De meeste backenders benaderen een probleem vanuit technieken, frameworks en libraries. Terwijl frontenders dit vaak vanuit designs en gebruikerservaring doen. Werken volgens de API First approach dwingt backend en frontend developers om in functionaliteiten in plaats van techniek te denken. Zo ontstaat een gemeenschappelijke taal waarin men kan discussiëren. Hiermee voorkom je dat er op discipline niveau teveel op details wordt ingegaan.

Daarnaast voorkomt het API schema onnodige discussies binnen het development team die niet bijdragen aan de kwaliteit van het project. Minder ‘bikeshedding’ zorgt voor duidelijkheid en focus. Door het gebruik van een API schema kan automatisch documentatie gegenereerd worden. Deze is altijd compleet en up-to-date. Hierdoor kan het project makkelijk worden overgedragen aan een nieuw team of het serviceteam, omdat alleen kennis van het API schema nodig is. 

App experience

De verwachtingen die eindgebruikers bij een webapplicatie hebben is afgelopen jaren veranderd. Eindgebruikers verwachten een snelle applicatie die op elke browser of elk apparaat moet werken en een ‘app gevoel’ geeft, bijvoorbeeld door het realtime verversen van data. Doordat alle interactiviteit zich op de frontend bevindt, is de webapplicatie opgebouwd als ‘echte app’. De gebruikerservaring voelt daardoor meer als een app aan dan als een website. 

Vanwege de vele voordelen zijn we – tot nu toe – erg enthousiast over de aanpak. Wil jij ook met de nieuwste technieken werken? Op onze werken bij pagina vind je meer informatie, waaronder video’s, over werken bij Netvlies. Wie weet tot snel!

Medewerker foto
Backend Developer Sam Zijlmans

Sam heeft een passie voor alles wat met innovatie en nieuwe technologie te maken heeft. Na werktijd en in het weekend is hij op de atletiekbaan en het voetbalveld te vinden. Ook slaat hij geen thuiswedstrijd van NAC Breda over.

Over Sam Zijlmans