Ben je opzoek naar een REST-API ontwikkelaar?
Lees dan hieronder de gehanteerde werkwijze van jelmert.nl voor het ontwikkeln van REST-API's!
Samen met het frontend team kan besloten worden om eerst de OpenAPI specificatie uit te werken. Op deze manier kan het frontend team gebruik maken van een mock-server en kan er gelijktijdig gewerkt worden aan de frontend en backend. Een meer traditionele aanpak is om eerst de backend te ontwikkelen en de OpenAPI specificatie hiermee te genereren. De frontend maakt toch het snelste meters als er een live backend aangeroepen kan worden.
Fit purpose: de juiste tool voor de juiste job. Als het om REST API's gaat is het Django rest-framework de juiste keuze. Met de nested serializers heb je optimale controle over de data die heen en weer wordt gestuurd. Het rest-framework biedt je de juiste tooling om snel, betrouwbare, functionaliteit te bouwen. Omdat het rest-framework gebouwd is op het Django framework kun je eveneens gebruik maken van de tooling en libraries uit het Django ecosysteem. Dit zorgt voor een optimale benutting van je manuren.
Wat API's zo mooi maakt is het automatisch testen van de endpoints. Zo ben je zeker van je zaak dat je geen onnodige fouten maakt.
Regelmatig laat je de automatische testen de balans opmaken om zo fouten vroegtijdig op te kunnen sporen.
Echter neemt dit niet weg dat er nog steeds handmatig getest moet worden.
Met een druk op de knop de nieuwe versie lanceren. Doordat alles geautomatiseerd is er geen specifieke kennis nodig van de infrastructuur of loginggevens van de server. De pipelines doen het voor je. We weten dat de kans dat onze software foutloos erg klein is, daarom kunnen we maar beter ervoor zorgen dat wanneer een fout gevonden wordt deze snel is opgelost. CI & CD zijn hierin onmisbaar.
Het liefst deployen we naar een platform as a service (PaaS). Op deze manier hebben we zelf geen interactie met het operationgsystem en hoeven we de servers zelf niet up-to-date te houden.
De kosten van de PaaS aanbieder reizen de pan uit of het eigen beheer van de servers is een vereiste. Dan deployen we rustig onze docker containers naar een eigen VSP. Doordat we docker als tussenlaag gebruiken zijn we binnen no-time up-and-running en hebben we altijd dezelfde versies van de onderliggende software. Onze installaties zijn daarom ook gegarendeerd stateles (op de database na natuurlijk). Dit maakt het extra gemakkelijk om een paar extra servers neer te zetten of om te verhuizen naar een andere partij.
Case study: Bodeminformatietool
Initieel was het plan om de backend te hosten op heroku maar hiervan werd op het laatste moment afgezien. De database werd gebackupped, git clone && docker-compose up deed de rest en met het terugzetten van de database backup naar de nieuwe server was de installtie klaar. Het wachten was op de wijziging van de DNS. In minder dan een uur was de migratie uitgevoerd en was het systeem up-en-running.