Reactive Webapps

Reaktiv?

Reaktive Webapplikationen oder zumindest deren Bezeichnung sind hoch im Kurs. Reaktive Applikationen sind flexibel und skalierbar. Sie sind fehlertolerant und reagieren im Fehlerfall anstatt still abzustürzen. Solche Webapps begegnen dem User interaktiv. Als Unterzeichner des Reactive Manifestos folgen hier aufgelistet die Kriterien eines reaktiven Systems:

Responsive:

Reaktiv sein bedeutet in angemessener Zeit Antwort zu geben. Geringe und konstante Wartezeiten geben der Benutzerin Zuversicht.

Resilient:

Die Applikation kann mit Fehlern umgehen und bleibt während dessen verfügbar. Teile des Systems können fehlschlagen ohne ihre umliegenden Komponenten oder gar das ganze System zu gefährden. Eine Möglichkeit dazu ist Replikation.

Elastic:

Bei schwankender Auslastung skaliert die Applikation entsprechend. Dabei ist es wichtig vorhersehbar zu bleiben.

Message Driven:

Reaktive Systeme verwenden asynchrones Messaging um die Komponenten zu trennen. So entsteht eine non-blocking Kommunikation wobei die einzelnen Komponenten weiterarbeiten können ohne auf eine Abhängigkeit warten zu müssen.

Scala, Play und Akka geben uns die Möglichkeit elegant nach diesen Grundsätzen zu entwickeln.

Weshalb sind uns diese Prinzipien wichtig?

Benutzer erwarten heute minimale Antwort- oder Reaktionszeiten im Millisekundenbereich. Gleichzeitig ist die Datenmenge bei vielen Applikationen im Vergleich zu früher immens gestiegen. Um diese Daten möglichst effizient zu verarbeiten rechnen wir auf mehreren Prozessorkernen gleichzeitig. Wenn die vertikale Skalierung nicht ausreicht ist es im Speziellen mit Akka einfach möglich die Last auf mehrere Nodes zu verteilen.

Wo setzen wir reaktive Systeme ein?

Unser Inkubatorprodukt ju§earch stützt sich im Bereich Datamining vor allem auf das Concurrency-Framework Akka. Mit dem bewährten Actor-System werden die Daten parallel verarbeitet. Die Resultate werden ohne zu blockieren mit Hilfe von ReactiveMongo in MongoDB aggregiert. Für gewisse Operationen verwenden wir direkt auf der MongoDB das Map-Reduce Paradigma. Auf der Client-Seite verwenden wir JavaScript um Resultate asynchron nachzuladen.

Weiter entwickelten wir in enger Zusammenarbeit mit Swisscom eine MVP-Applikation zur Verifikation Swisscom-eigener Webservices. Bei einer solchen Integration von Umsystemen mit verschiedenen Antwortzeiten und unterschiedlicher Verfügbarkeit muss das System reaktiv sein. Die Interaktion darf die systemeigenen Prozesse nicht blockieren. Client-seitig verwendeten wir AngularJS um auch dort auf asynchrone Kommunikation mit dem Backend zu setzen.