In welk opzicht is Reactive anders dan de applicaties die we gewend zijn? In een andere blog heb al eens een aantal andere stijlen op een rijtje gezet. Nu gaan we dat eens vergelijken.
Reactive versus CRUD
De meeste JEE applicatie muteren gegevens in een database volgens CRUD. Het is soort lifecycle, gegevens worden gecreerd, geraadpleegd, update en delete. Reactive systemen zijn message driven. Een message wordt eenmalig verwerkt. De message kan natuurlijk worden bewaard, maar een update, dat is een nieuwe message.
Asynchroon versus synchroon
Webapplicatie werken request response. Reactive applicatie werken asynchroon.
Eventual consistency versus ACID
Een database kent serializable transacties. Een transactie is atomair, ze kunnen elkaar niet beïnvloeden. Je kunt altijd een volgorde vinden waarin de transacties als ze achter elkaar gezet worden het zelfde resultaat opleveren, als wanneer ze parallel draaien. De database vergrendelt gegevens, als een andere transactie bezig, dan wordt de toegang gesynchroniseerd.
Reactive applicaties sturen berichten, die weer andere berichten triggeren. De ene component gaat zijn gegeven bijwerken, een andere even later. Waardoor tijdelijk gegevens niet met elkaar kloppen. Uiteindelijk komt het allemaal wel weer goed, en dat noemen we dan Eventual consistency. We verliezen niks, maar het duurt even.
Non-deterministisch versus serializable
Reactive systemen zijn hierdoor non-deterministisch. Serializable niet. Er zijn overigens niet zo heel veel databases die dat echt goed kunnen.
Event sourcing versus state update.
Een component in een reactive systeem weet niet altijd wat de status is van een gegeven. Hij moet het uitrekenen uit de beginstand en de binnengekomen berichten. Met Hibernate heb je meteen de actuele versie van een CRUD record te pakken.
Gedistribueerd versus centrale database
Een reactive applicatie kan bestaan uit meerdere autonome micro services. Dit zijn een soort subsystemen die autonoom kunnen worden onderhouden. Dit kan ook wel met database centrische Jee applicaties, maar het is niet zo makkelijk een join te doen over twee databases, en in het algemeen is een meer monolithische architectuur gebruikelijk.
Message driven versus enterprise bean.
Binnen reactive zijn message de centrale aandriving. Bij JEE zijn dat de enterprise beans, die via OR-mapping de persistentie regelen.
Microservice versus monolithisch.
Al eerder genoemd worden reactive applicaties opgedeeld in modulaire subsystemen. Dit maakt zaken als upgrades wel makkelijker. Als de interfaces met andere systemen compatible blijven kan ieder onderdeel een eigen lifecycle en evolutie ondergaan, en kunnen delen vervangen worden. Dit is een voordeel ten opzichte van applicaties die nauwer gekoppeld zijn.