Er is dezer dagen een grote beweging weg van de monolithische enterprise server-applicatie naar een event-driven, reactive model. Maar wat wordt daar juist mee bedoeld?
Het idee is dat aparte logica apart beheerd en uitgevoerd wordt. In een traditionele architectuur krijgt elke binnenkomende request de onverdeelde aandacht van één server thread. Die server thread behandelt de vraag volledig. We noemen die manier van werken ‘blocking’. Voor elke actie waarop de server moet wachten, blijft de bijhorende thread ook wachten. Het kan bijvoorbeeld gaan om een opzoeking in de database of een vraag aan een aparte webservice.
Het voordeel van het traditionele model is dat het vrij eenvoudig is. Het is gemakkelijk te begrijpen en gemakkelijk te implementeren. Het grote nadeel is dat er veel tijd verspild wordt met wachten. Dat wordt vooral een probleem op drukke servers, waar threads nutteloos geparkeerd worden terwijl nieuwere requests afgehandeld zouden kunnen worden.
Het event-driven alternatief is gebouwd rond het principe van events. Een applicatie wordt opgesplitst in een losse structuur van gespecialiseerde modules. Werk wordt uitgewisseld via zogenaamde events: elke module gaat op zoek naar het soort werk dat het kan oplossen, en afgewerkte taken worden als event doorgegeven.
Als we het erg eenvoudig voorstellen zouden we een event kunnen vergelijken met een doos. In die doos zit een beschrijving van het werk dat gedaan moet worden, en er staat bij welke module verwittigd moet worden als dat werk af is.
Reactive programming gaat in dezelfde lijn verder. Bij reactive programming wordt de aanzet van events niet langer noodzakelijk gezien als de actie van een gebruiker (een klik op een link, typen in een invoerveld ...). Het idee is dat de bron van een event ook elders kan liggen. Misschien heeft een webservice nieuwe data, of zorgt het werk van een andere gebruiker voor nieuwe data. Die nieuwe data zorgt dan voor een update van wat de gebruiker ziet.
Event-driven development en reactive programming zijn krachtige concepten die een aantal mooie voordelen meebrengen.
Deze vorm van ontwikkelen promoot zogenaamd ‘loose coupling’ van code. Loose coupling betekent dat er zo weinig mogelijke harde verbindingen gemaakt worden tussen de verschillende logische domeinen van code. Loose coupling wordt algemeen beschouwd als een krachtig instrument om code onderhoudbaar en foutvrij te maken.
Daarnaast leent de methodiek zich ook perfect tot het opzetten van ‘microservices’, en daar zien we als groot voordeel ook weer onderhoudbaarheid, maar ook schaalbaarheid. Met schaalbaarheid bedoelen we dat het eenvoudig is om meer servercapaciteit te voorzien als de applicatie een groot volume te verwerken krijgt. Met monolithische applicaties is dat traditioneel een complex probleem.
Ook zorgt de methodiek voor nieuwe en voordelige vormen van hosting in de cloud. We spraken in dit artikel al over ‘serverless’ als manier om een applicatie tegelijk schaalbaar en economisch te houden.