Seite 4: Fazit

Inhaltsverzeichnis

Weiterführend wäre es jetzt denkbar, mit Stream-Prozessoren zu arbeiten, und statt wie bisher vom Client eine aktualisierte Userliste zu schicken, diese über Kafka zusammenbauen zu lassen. Doch eins ist längst bewiesen: Es geht! Bleibt jedoch die Frage: Sollte man es tun?

Bis auf ein paar sehr spezielle Anwendungsfälle ist die Antwort allerdings ein generelles Nein. Wie man bei der Konstruktion des Beispiels gemerkt hat, wird hier die Kafka-eigene Persistenz für etwas wofür sie nicht gedacht ist, ausgenutzt. Sie soll nur sicherstellen, dass Consumer genügend Zeit haben, eine Nachricht definitiv zu verarbeiten, und dass Crashes einer Kafka-Instanz zu möglichst wenig Datenverlust führen. Ebenfalls sehr konstruiert ist der Fakt, dass Kafka hauptsächlich als Nachrichtenverteiler fungiert. Echte Backend-Logik ist oft ungemein komplexer und mit Stream-Prozessoren nur schwer abdeckbar. Dass es überhaupt funktionierte, unterstreicht jedoch die Vielseitigkeit von Kafka.

Betrachtet man nochmal die Daten und deren Weg fallen zwei Dinge auf. Erstens war die Verbindung, weil die Kommunikation komplett über Events ablief, jeweils lose und nicht blockierend gewährleistet. Zweitens hat jede Nachricht denselben Weg genommen, um von Client zu Client zu gelangen. Der Datenfluss erfolgte also undirektional – ein Konzept, das Facebook bei seiner Flux-Architektur aufgegriffen hat. Beides sind gute Ansätze in der Umsetzung von Webanwendungen, sollten unabhängig von Kafka auch in anderen Anwendungen eingesetzt werden: Dann allerdings nicht bloß als ein Versuch, eine dumme Idee in die Tat umzusetzen.

Frank Goraus
ist Lead Developer bei der MATHEMA Software GmbH. Seit mehr als einem Jahrzehnt beschäftigt er sich mit der Entwicklung von JEE- und Webanwendungen. Dabei begleitet er die Projekte der Kunden von der Datenbank übers Backend bis hin zum Frontend. Sein Steckenpferd sind Frontend-Technologien und die damit verbundenen Herausforderungen und Chancen für die Zukunft der Webentwicklung. (bbo)