Kort door de bocht gezegd hebben alle eerdere onderdelen van wat we bij rb2 doen, weinig zin als er niet ook gekozen wordt voor de API als basis, oftewel API-first. API-gedreven integraties zorgen ervoor dat je digitale business naadloos in elkaar past. Wil je de overstap maken van monoliet naar microservices, dan zorgen API's dat dit mogelijk is. Sterker nog, eigenlijk zijn microservices en API's nagenoeg identieke bouwblokjes binnen development.
Er is uiteraard wel een verschil tussen API's en microservices in wat ze uiteindelijk 'doen'. Waar microservices meer in het 'hoe' zitten van ontwikkelen, kun je API's beter met 'wat' typeren. Je zit dan al vrij dicht tegen businessprocessen aan. Welke specifieke API-stijl je gebruikt, is niet echt iets waar je je druk om hoeft te maken; of het nu bijvoorbeeld REST, gRPC of Graph is, het maakt voor wat een API doet niet zoveel uit.
Menselijke maat
Dat API's zich vooral bezighouden met het 'wat' binnen development, vertaalt zich uitstekend in de opvatting dat de API in de eerste plaats een interface voor mensen is. Het brengt namelijk een zeker begrip met zich mee voor de behoeftes van ontwikkelaars, onder andere vanwege de simpele manier van documenteren. Het zorgt ook voor het duidelijk kunnen focussen op een specifiek doel, niet op twintig doelen tegelijkertijd.
Daarnaast lokken API's design thinking uit en daarmee een goed ontwerp dat naadloos aansluit bij wat klanten eruit willen halen. Dat is in de basis ook iets menselijks, je neemt de mens als uitgangspunt bij het bouwen van applicaties. Je bouwt blokje voor blokje richting een bepaalde synthese in het ontwerp. Doordat je services expliciet van elkaar ontkoppelt, hou je overzicht, zelfs in complexe omgevingen.
Bij het traditionele systems thinking moet er vooral veel geanalyseerd worden nadat er een monoliet is gebouwd, waarbij er een zekere mate van zogeheten analysis paralysis op kan treden. Het is dan niet meer duidelijk waar je als ontwikkelaar precies mee bezig bent. Dat heeft uiteraard ook zijn weerslag op hoe en wanneer de klant er uiteindelijk mee aan de slag kan.
Bouwen voor de toekomst
Als je een nieuwe applicatie-omgeving gaat bouwen, zoals wij regelmatig doen voor klanten, dan wil je uiteraard dat er zoveel mogelijk voor de toekomst wordt ontwikkeld. Met andere woorden, wij bouwen graag iets waar we min of meer zeker van zijn dat het langere tijd mee kan, ook als de behoeftes van onze klanten veranderen. Met API's is dat mogelijk, zelfs voor toekomstige wensen waar je nu nog niet eens naar kan gissen.
Toekomstige wensen op het gebied van koppelingen bij applicaties kunnen intern zijn, maar zeker ook extern. API's zijn namelijk bij uitstek geschikt om relatief eenvoudig een koppeling te maken met zaken in de buitenwereld, zoals applicaties van en bij derden. Op dit vlak helpt het dan juist ook enorm dat je goed kunt achterhalen wat een bepaalde API doet en waarom hij bestaat. Exact weten wat hij doet voor je is een belangrijke voorwaarde om hem open te stellen voor derden.
Uiteindelijk ligt deze wens van schaalbaarheid en continu innoveren aan de basis van al onze keuzes op het gebied van ontwikkelomgeving. Of dat nu de keuze is voor cloud-native en -agnostisch met microservices, CI/CD of in dit geval API's.
-
-
-
-
0 Reacties Bewaren