Deep-Dive: Das ist der Tech-Stack von t3n (3)
t-3-n. Oder doch “ten”? Weißt du eigentlich, wie man t3n richtig ausspricht? Wenn du die ursprüngliche Bedeutung des Namens kennst, wirst du schnell auf die Lösung kommen: t3n steht nämlich ursprünglich für TYPO3 News. Doch wie viel TYPO3 steckt eigentlich noch heute in den Systemen von t3n? In einem dreiteiligen Blogartikel wollen wir dir einen tiefen Einblick in unseren Techstack geben. Im dritten Teil erfährst du, wie wir mit noch unbekannten Daten umgehen, warum wir immer mehr eigene Daten erheben wollen und was wir uns für die Zukunft vorgenommen haben.
Von unbekannten Daten bis EventSourcing
Nach außen hin haben wir mit Schritt 1 und 2 alles erreicht, was für die User:innen von t3n.de relevant ist — wirklich etwas an den bisherigen Systemen verändert haben wir aber bis hierher noch nichts. Unser Ziel insgesamt ist es, die Breite der Systeme zu reduzieren, um weniger Maintenance-Aufwand zu haben und uns wirklich auf unsere Business-Domain konzentrieren zu können. In Zukunft wollen wir also vielleicht einzelne Systeme zusammenlegen, gegen andere austauschen oder neue SaaS-Services neu anbinden. Letzteres ist übrigens total easy. Alles was es dazu braucht, ist ein MicroService, der unseren Graph erweitert und als Backend-System den SaaS-Service nutzt.
Aber zurück zu unseren eigenen Systemen: Wie modelliert man eigentlich Daten, von denen man noch gar nicht weiß wie sie aussehen? Nehmen wir zB. mal die Daten unser User:innen auf t3n.de. Wir können heute noch nicht genau wissen, welche Views wir auf t3n.de in 2–3 Jahren haben und welche Daten wir dafür konkret benötigen werden. Wir müssen also auch hier wieder sehr flexibel sein. Es ergibt einfach keinen Sinn, jetzt beispielsweise irgendwelche Systeme zusammenzulegen, wenn wir gar nicht wissen, wie wir die Daten später brauchen werden.
Unsere Lösung für diese Problem lautet EventSourcing. Wem das nichts sagt: Ich versuche es in drei Sätzen zu erklären (und lasse hierbei bewusst ganz viele Details und Feinheiten aus, um es kurz zu halten): Der entscheidende Punkt hier ist vor allem, wie Daten persistiert werden. In einer „klassischen” DB habt ihr beispielsweise eine Tabelle für Userdaten. Dort gibt es eine Spalte „Wohnort”. Wenn jemand nun in der UI seinen/ihren Wohnort ändert, aktualisiert ihr den Wert in der Spalte. Aus Dortmund wird so z.B. Hannover.
Beim EventSourcing läuft das anders: Es gibt grundsätzlich erstmal kein wirkliches User-Modell. Wir persistieren nur Änderungen an Daten, nicht den geänderten Datensatz. Das machen wir, in dem wir sogenannte Events (oder auch Ereignisse) in einem EventStore persistieren. Der EventStore könnte z.B. eine Tabelle in einer DB sein mit ein paar Spalten — unter anderem EventName und EventPayload. Ändert nun ein User seinen Wohnort, würden wir in den EventStore ein Event mit dem Namen “UserHatWohnortAktualisiert” und den Daten “{“user”: “uuid”, “city”: “Hannover”}” persistieren.
Wir speichern also sozusagen immer nur jeweilige die Änderung bzw. das Event mit den entsprechenden Daten. Jetzt stellt euch vor, dass ein User im Laufe der Zeit 100 Events in dem Store stehen hat. Über die API kommt nun eine Anfrage nach den aktuellen Daten. Wo bekommen wir die her? Dafür gibt es sogenannte Projections. Projections sind eine Art Sicht auf die Daten — und die ist ganz flexibel erstellbar. Unterm Strich habt ihr eine Klasse in eurem Code (auch Projector genannt), die auf die Events lauscht. Immer wenn das Event “UserHatWohnortAktualisiert” gespeichert wird, nimmt dieser Projector die Daten aus dem Event und schreibt die Änderungen in eine andere Datenbank. Bei uns konkret liegen diese Projections z.B. in ElasticSearch und sind damit super verfüg- uns skalierbar für die MicroServices.
Das gute an diesem Konzept ist, dass wir alle Veränderungen speichern und nicht den aktuellen Stand. Wenn wir in zwei Jahren zB neue Anforderungen an ein View haben können wir einen neuen Projector erstellen, der ein Readmodel bzw. bei uns ein DocumentType in ElasticSearch erstellt, der genau für diesen Use-Case optimiert ist. Dann lassen wir alle Events einmal gegen den Projector laufen und haben ein performance-optimiertes Readmodel für genau diesen Use-Case. Wir müssen uns also heute keine Sorgen mehr darum machen, wie die Daten in einigen Jahren modelliert sein müssen. Wir modellieren Sie uns einfach dann, wenn wir sie brauchen — und verwenden dafür alle historischen Ereignisse und Daten! Dadurch haben wir uns auch hier wieder ein großes Stück Flexibilität in unseren Stack geholt.
Vom DataWarehouse bis zur eigenen Datenerhebung
In unserer Branche bekommen Themen wie First-Party-Data eine immer wichtigere Bedeutung. Und damit wird für uns eine Disziplin immer wichtiger: DataWarehouse. Seit einiger Zeit haben wir uns auch in diesem Bereich breiter aufgestellt und professionalisiert. Wir versuchen mehr und mehr Daten selbstständig zu erheben, um so auch auch eigene Auswertungen und Performance-Messungen machen zu können. Wir haben dafür zB eine Apache-AirFlow-Instanz mit mehreren sogenannten DAG’s, um ETL-Prozesse abzubilden. Wir stehen hier zwar noch recht weit am Anfang, haben aber umso mehr Möglichkeiten, hier selber Daten zu erheben.
Vom flexiblen Hosting bis zum neuen Stack
Wo stehen wir jetzt heute und wo wollen wir hin? Wir haben als Team in den letzten 2 Jahren eine Menge geschafft. Wir sind schon längere Zeit komplett flexibel im Hosting dank der Google Cloud. Wir haben schon heute alle unsere Datenquellen mit GraphQL-APIs versehen und sie somit in einem einzelnen Graphen verfügbar. Unser Stack hat in der Corona-Zeit mehrmals beweisen können, wie flexibel er ist und wie schnell wir auf neue Produkt-Anforderungen reagieren können. Wichtige Teile von t3n.de laufen schon heute über unser Next.JS Stack.
Derzeit arbeiten wir in der Tat viel an den internen Workflows, die über unsere Private API gesteuert werden. Es gibt noch einige weitere Baustellen in unserem neuen Stack. Wir haben viele Learnings in der Zeit machen dürfen und versuchen diese wieder bestmöglich zu integrieren. Das DataWarehouse-Thema wird für uns immer spannender und die Zusammenarbeit von den Dev’s mit den DevOps immer wichtiger und näher. Wir nutzen die Cloud immer mehr und nativer.
Und dennoch ist noch viel zu tun. Von unseren drei Schritten der Migration stecken wir vermutlich irgendwo zwischen dem zweiten und dritten Schritt. Und diese spannende Reise ist noch lange nicht zu Ende. Wir haben aber mit der eingeschlagenen Richtung ein gutes Gefühl und möchten diesen Weg weiter gehen.
Kennst du schon die anderen beiden Teile zu diesem Deep-Dive? Scroll doch einfach mal weiter, wenn du Bock auf mehr Einblicke hast.
Oder bist du schon richtig angefixt? Dann schau doch mal auf unserem Jobportal vorbei. Wir haben einige coole Stellen rund um den spannenden Tech-Stack von t3n ausgeschrieben.
Mehr Infos gibts hier: https://t3n.de/jobs-bei-t3n/
