Mobiele app laten ontwikkelen?

Ontwikkelaars: zó bouw je een goede API met en voor frontenders

We mogen in onze blogs graag even vooruit kijken naar trends, maar nu gooien we het even over een andere boeg. Tijd voor een artikel voor onze mede-appontwikkelaars. Tijd voor een lofzang over (en tips over de aan de slag gaan met) API’s.

Goede API’s (Application Programming Interface, daar staat het voor trouwens) zijn één van de grootste succesfactoren voor het technische slagen van een mobiele app. Ze slaan een brug tussen één of meerdere database-omgevingen en mobiele apps en websites/applicaties.

Voor de eindgebruiker is een API geheel onzichtbaar, maar iedere zichzelf respecterende app-ontwikkelaar zal beamen dat de API één van de meest belangrijke onderdelen is van een succesvol ontwikkelde mobiele app of webapplicaties. Bij Freed weten we inmiddels welke belangrijke factoren er om de hoek komen kijken wanneer er een (succesvolle) samenwerking wordt gestart.

Dit zijn onze acht vlotte tips; dingen om rekening te houden bij het werken met API’s:

1. Make love with the frontend

Ben je backend ontwikkelaar? Start dan met het verdiepen in het uiteindelijke kanaal waarvoor de API ontwikkeld gaat worden. Bekijk de wireframes, verdiep je in de gebruiker en bestudeer de schermvoorstellen. Onbewust ga je alvast nadenken over oplossingsrichtingen en zonder dat je er erg in hebt droom je ’s nachts over de perfecte queries die je los mag laten om tot de meest snelle, efficiënte en generieke API te komen.

Dit benadrukken we, omdat een API vaak een natuurlijke scheidslijn is tussen twee teams binnen een groter (app) project. Het ene team werkt aan de frontend van de app terwijl een ander team zich buigt over de API. In deze werkwijze schuilt gevaar. Niemand houdt van onaangename verrassingen – en dat geldt ook voor frontend ontwikkelaars. Vermijd dus verrassingen en sluit de API- en frontend-ontwikkeling goed op elkaar af. Probeer de API één of twee sprinten voor te laten lopen maar werk in hetzelfde ritme, zelfs als je werkt met teams op afstand. Door gelijk op te trekken, kunnen beide partijen schakelen als iets niet helemaal loopt zoals verwacht.

 alt=

2. Laat de server het werk doen

Stop alle intelligentie in de API! Een hele simpele maar toch ook gouden regel als het gaat om de ontwikkeling van een API. Des te meer functionaliteit en intelligentie er in de API kan worden gestopt, des te makkelijker het zal worden om deze functionaliteit centraal te wijzigingen op het moment dat dit nodig is. Werken vanuit de API is veel slagvaardiger dan moertjes en boutjes aan uitsluitend de backend of frontend, serverside of clientside aanpassen.

3. Bespaar werk, documenteer!

Wil je een frontend team echt goed in de watten leggen? Zorg dan voor overzichtelijke en actuele documentatie. Swagger is een voorbeeld van tooling waarmee API-ontwikkelaars eenvoudig punten (of een taart) kunnen scoren tijdens de eerstvolgende gezamenlijke meeting.

 alt=

4. Pimp je foutmeldingen

Zorg voor duidelijke foutafhandeling in de response van de API. Definieer duidelijke en consistente foutcodes en dito foutmeldingen zodat deze op een generieke manier in de app kan worden verwerkt. Frontenders worden helemaal gek van de ‘Server error response 500’ meldingen met daaronder een hele rits aan gecompileerde lineaire algebra die alleen gesnapt wordt door de API wizzkids. Definieer verwachte of opgedoken fouten zoveel mogelijk – zo kan iedereen sneller schakelen.

5. Test geautomatiseerd

‘De testserver is bijgewerkt hoor!’ ‘Nee, het gaat nog steeds niet goed!’ is wellicht één van de meest gebruikte Slack conversaties tussen backend-developers en frontenders. Oeps.

Het is goed om een geautomatiseerd testplan te schrijven voor API’s zodat bij iedere oplevering een bepaalde mate van standaard kwaliteit wordt gewaarborgd. We merken nog heel vaak dat, als er links iets wordt aangepast, er helaas rechts iets omdondert. Heel vaak kan dit eenvoudig voorkomen worden door een geautomatiseerd testplan. Dat voorkomt onnodige vertraging gedurende een sprint- of ontwikkelproces.

 alt=

6. Doe aan versiebeheer

Het begint vaak bij de klant/ productowner alweer te jeuken voordat zelfs de eerste versie van de app het levenslicht in de App Stores heeft gezien. Nieuwe features en verbeteringen in de bestaande app staan alweer in de backlog.

Het is goed om van te voren om na te denken over versiebeheer van de API. Immers: wijzigingen van features en feature requests betekenen vaak ook aanpassingen in de API. Hoe gaan we om met bestaande apps die al in de stores staan? Blijven deze backwards compatible? Wordt er naast de api/v1 ook een api/v2 gepubliceerd? Allemaal vragen die van te voren moeten zijn getackled.

7. Scheid de servers

Het inrichten van een OTAP-omgeving (sorry als we in opa vertelt-taal praten; Ontwikkeling, Test, Acceptatie en Productie) is wellicht in sommige gevallen een beetje ‘too much’ van het goede.

Maar probeer in ieder geval wel te werken met een ontwikkelserver (waar de API-onwikkelaars naar hartelust hun GIT-kennis op mogen botvieren), een acceptatieserver (een stabiele oase van rust voor de frontend ontwikkelaars) en een productieomgeving waarover geen enkele twijfel mag bestaan over de stabiliteit en de bereikbaarheid van de services.

8. Daag jezelf uit op de veiligheid

Is je API helemaal veilig? Jij mag het denken, maar onze tip is om experts ernaar te laten kijken. Laat je API eens onder handen nemen door een stel legale hackers. Zie dit vooral als een plezierige en leerzame stap gedurende de ontwikkelfase en denk vooral aan de ongewenste krantenkoppen die je wellicht hiermee kunt voorkomen. Ja, het kan wat confronterend zijn, maar wat wordt je er wijzer (en beter!) van.

 alt=

Zo. Best veel niet?

Het is een bloemlezing uit de inmiddels jarenlange ervaring waaruit we kunnen putten. We hopen dat we enkele bruikbare tips hebben kunnen delen. Mocht je vragen hebben over het inzetten van een API tijdens een mobiel traject of wil je gewoon onze nieuwe koffiemachine (v2.1) eens uitproberen? Mail of bel gerust hoor. Een afspraak is zo gemaakt. Sneller dan een dichtgetimmerde, op alle vlakken vlammende API in ieder geval. 😉