Tech

Backend en frontend in harmonie: hoe je samenwerking, processen en oplevering optimaliseert

31 mei 2021

Hoe elimineer je onnodig veel iteraties in de processen tussen je frontend en backend teams? Onze eigen Front End Tech Lead, Tom Parsons, heeft er één sleutelwoord voor: afspraken!

code on macbook

Tom: “Als ik nadenk over mijn ontwerpstrategie is het eerste dat ik mezelf afvraag: “hoe kan ik dingen verbeteren/vereenvoudigen?

Door deze simpele vraag samen met mijn team te beantwoorden, hebben we één van de meest monotone aspecten van de relatie tussen backend en frontend kunnen verbeteren.

Het komt allemaal neer op één ding:

Afspraken.

The ‘90s, when GB and France met in the middle whilst drilling the Channel Tunnel (I refer to this image frequently when explaining this approach).

The ‘90s, when GB and France met in the middle whilst drilling the Channel Tunnel (I refer to this image frequently when explaining this approach).

Ik vind de bovenstaande foto prachtig. Hij illustreert hoe twee teams elkaar in het midden ontmoeten bij het doorboren van een tunnel. Het doet me denken aan het knappe staaltje engineering dat hieraan te pas kwam. Gelukkig hoeven mijn team en ik ons niet door zulke complexe bouwwerken te worstelen.

Er zijn echter wel vergelijkingen met ons werk.

Software Engineers lopen vaak tegen onbeantwoorde vragen aan bij het bouwen van applicaties die bijvoorbeeld van APIs afhankelijk zijn. Zelfs met een gedetailleerde voorbereiding en planning kom je niet altijd direct tot de gewenste resultaten.

Hieronder volgt een anekdote van een uitdaging die we samen getackeld hebben.

Hoe het hiervoor ging

Stel je het volgende voor.

Een project gaat van start. Het backend team werkt aan het API eindpunt en stuurt dit naar het frontend team, dat vervolgens gaat coderen.

Het is een veelgebruikte aanpak, waarbij twee teams synchroon werken, maar niet per se in goede harmonie. Er is veel iteratie benodigd, waarbij soms issues of blokkades ontstaan.

Frontend engineers herkennen waarschijnlijk het wachten op de backend teams, die met modellen moeten komen op basis waarvan jouw frontend features gebouwd kunnen worden. Hierbij weet je niet van tevoren wat optimaal zal werken en wat niet. Talloze andere issues die onder jouw verantwoording vallen, stapelen zich ondertussen op.

Ik herken dit maar al te goed. Sterker nog, tot vorig jaar was ik gewend aan deze manier van werken. De alternatieve - naar mijn mening ook betere - aanpak, is voor de meeste bedrijven een grote verandering die veel tijd kost om te implementeren. Wijzigingen in processen en werkwijzen kunnen een intensief verandertraject zijn binnen teams.

Maar zodra de nieuwe techniek geïmplementeerd is, kijk je nooit meer om.

Hoe het nu gaat

Het grootste onderdeel van de verandering die wij hebben doorgevoerd, is eigenlijk niets bijzonders.

Het is planning.

De eerste stap is het opstellen van de planning en het achterhalen van alle vereisten door de projectleiders. We hanteren onder andere specifieke ontwerpen en minimumeisen. Gewoonlijk hebben de product- en design teams het grootste deel van kenmerken al gespecificeerd.

Vervolgens stellen we afspraken op.

We leggen alle gegevens en vereisten voor het project vast in een contract. De afspraken in het contract vormen de basis van waaruit we te werk gaan.

Je zou het natuurlijk ook een andere naam kunnen geven, maar wij gebruiken de term “contracten”, want dat zijn het: overeenkomsten waarmee beide partijen instemmen.

Als resultaat kan de oplevering versneld worden: we komen samen op een vooraf bepaald punt, waardoor de oplevering weken of zelfs maanden wordt verkort.

De contracten vormen het middelpunt waarop beide teams elkaar ontmoeten.

Wanneer de afspraken duidelijk zijn kunnen de teams parallel aan de slag, waarbij constante communicatie dus ook minder nodig is. Als resultaat kan de oplevering versneld worden: we komen samen op een vooraf bepaald punt, waardoor de oplevering weken of zelfs maanden wordt verkort.

Deze aanpak is direct te implementeren. Daarbij kunnen bepaalde technische wijzigingen veel impact hebben. Dit hangt samen met:

  • Documentatie

  • Type generatie

  • Atomaire / moleculaire componenten

Alle puzzelstukjes komen samen

Vanuit het backend perspectief is voor alle APIs documentatie benodigd. Bij Funding Options maken we gebruik van Swagger/OpenAPI (er zijn ook andere mechanismes beschikbaar). Vervolgens gebruiken we de documentatie om TypeScript types te genereren middels DtsGenerator. Deze worden ingezet voor de front end toepassing.

Wanneer de typen beschikbaar zijn kun je beginnen met het uitbouwen van de componenten.

Onze benadering is atomair/moleculair.

We gebruiken Storybook om de componenten en varianten te ontwikkelen. In combinatie met type-gedreven functies passen de componenten bij de ontwerpen. Ze worden vervolgens getest op basis van de typen die we hebben, dus er is geen werkende API nodig.

Uiteindelijk stelt onze aanpak ons in staat om verschillende teams parallel te laten werken en de oplevering te versnellen. Alle mogelijke afwijkingen van onze componenten kunnen worden opgelost, omdat we de geautomatiseerde typen gebruiken op basis van de documentatie.

De betrouwbaarheid van onze codering is als gevolg daarvan ook verbeterd.

Maar bovenal heeft het nieuwe proces veel onnodig gecompliceerde communicatie tussen teams geëlimineerd. Door elkaar in het midden te ontmoeten, oftewel toe te werken naar de gezamenlijk bepaalde basis, weet iedereen hoe alles eruit moet zien.

We kunnen zelfs zeggen dat onze frontend en backend teams nog nooit zo goed hebben samengewerkt als nu.

Mogelijke obstakels

Geen enkele aanpak, ook deze niet, is compleet vrij van mogelijke obstakels. Echter, een degelijk QA-proces helpt wel in het vermijden van blockers.

Een mogelijke blocker is het moeten uitbreiden van de APIs; dit kan vertraging voor de frontend teams veroorzaken. Maar naar mijn mening wegen de voordelen van dit proces alsnog zwaar op tegen de nadelen. Ik zou zeggen: give it a try!

Auteur: Tom Parsons, Front End Tech Lead

Tom Parsons

Tom Parsons

Front End Tech Lead

)))

Elke maand handige tips en inzichten ontvangen?

Schrijf je hier in om onze maandelijkse update direct in je inbox te ontvangen.