Deep-Dive: Das ist der Tech-Stack von t3n (2)
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 zweiten Teil erfährst du, wie wir uns vom Verlag zur Plattform entwickeln, warum unsere größte Herausforderung die Daten sind — und wie wir damit umgehen…
Unsere Vision: Vom Verlag zur Plattform
Unsere Produktvision, für die wir in der Product-Unit arbeiten, lautet „vom Verlag zur Plattform”. Wir möchten uns technisch so aufstellen, dass wir eine Plattform betreiben können bzw. unser technischer Stack einer Plattform gleichkommt — unabhängig davon, wie sich das Feature-Set von t3n entwickeln wird. Nun bietet unsere derzeit historisch gewachsene Struktur Vor- als auch Nachteile. Im Bereich des Hostings sind wir schon heute gut und vor allem für die Zukunft flexibel aufgestellt. Im Bereich der Anwendungen arbeiten wir schon seit längerer Zeit hinter den Kulissen.
Unser derzeitiges Kernproblem für die Zukunft sind Daten. Uns zwar vor allem, wo und wie die Daten gespeichert sind. Die Idee einer Plattform bedingt immer auch, dass man flexibel Zugriff auf unterschiedliche Daten hat, da alles ein bisschen „integrierter“ ist. Die derzeitige Trennung der einzelnen Bereiche in eigene Projekte und Apps hilft uns da leider nicht. Ganz im Gegenteil: Durch diese Trennung haben wir mit der Zeit eine Art von „Datensilos“ geschaffen. Um Daten aus der einen App in einer anderen anzuzeigen, müssen serverseitig entweder eine Menge Sync-Prozesse stattfinden und/oder Daten live aus den jeweiligen anderen Applikationen abgefragt werden. Klar, denkbar wäre auch eine Art globaler Suchindex in ElasticSearch, hier würde man dann aber unter Umständen die Business-Logik ausklammern müssen.
Kurzum: die derzeitige Struktur ist noch nicht ideal. Neben der Datenhaltung ist aber auch der „View“ zur Zeit ein Problem. Die einzelnen Portale rendern derzeit Ihre eigenen Templates. In einer Plattform ist die Denkweise aber eine andere: Wir wollen hier viel flexibler sein, was wir wo und wie rendern.
Von einzelnen Services zum JAM-Stack
Aber wie gelingt uns das? Wir haben länger über mögliche Lösungen nachgedacht und einen für uns guten Weg gefunden. Wir möchten langfristig den View von der Business-Logik lösen — also quasi Read und Write voneinander abkoppeln und uns so zu einem mehr oder weniger klassischen JAM-Stack entwickeln. Dieser Task ist aber in Summe kein einfacherer und kann „nicht mal eben schnell” erledigt werden. Wir werden also nicht in eine Situation kommen, in der wir eine Zeit lang arbeiten, dann einen Schalter umlegen und die Infrastruktur hat sich geändert.
Diese Aufgabe muss vielmehr in iterativen Schritten durchgeführt werden und wird uns über die nächsten Monate und darüber hinaus begleiten. Wir versprechen uns von diesem Ansatz vor allem viel mehr Flexibilität in der Zukunft. Wenn wir das Rendern von Templates vom Backend und damit auch den Daten entkoppeln könnten, könnten wir jede zukünftige Anforderung in einem Template realisieren und kommen so dem Plattformgedanken viel näher. Doch wie geht man so ein riesiges Thema vernünftig an?
Was uns klar war und ist: Wir wollen eine Art von Klammer über unsere Systeme bilden — und dabei sprechen wir zunächst einmal gar nicht so sehr von einer optischen. Dass die Portale auch rein optisch viel näher zusammenrücken müssen ist total klar, wir interessieren uns aber erst einmal viel mehr für die Daten und Business-Logik.
Wo wir aber schon einmal kurz das Thema UI und Frontend streifen: Wir haben uns als Team dafür entschieden, zukünftig mit React arbeiten zu wollen. Mit dem Framework Next.JS haben wir alles an der Hand, was wir für die Zukunft brauchen werden. In unserem Storybook erarbeiten wir erste neue Komponenten, die wir später verwenden wollen.
Um besagte Klammer über unsere jetzigen Systeme bilden zu können, wollen wir langfristig in drei Schritten vorgehen. Daten verfügbar machen, Templates anpassen, Business-Logik vereinfachen.
Von Datentöpfen bis GraphQL
Im ersten Schritt geht es darum, Daten schlichtweg verfügbar zu machen. Derzeit haben wir viele unterschiedliche Datentöpfe, wir würden allerdings gerne alle Daten über eine Schnittstelle verfügbar haben. Daher haben wir uns für ein API mit GraphQL entschieden. Die Idee dahinter: Alle unsere Systeme exposen eine GraphQL-API. Wir stitchen die einzelnen APIs zusammen und erhalten so einen großen federated-Graph, über den wir alle Daten abfragen können.
In den ersten Versuchen haben wir das Stitchen noch selbst gemacht. Mittlerweile nutzen wir dazu aber den Service Apollo Studio. Apollo Studio managed dabei den Graph, ist in unsere CI&CD Prozesse eingebunden und stellt sicher, dass der Traffic entsprechend innerhalb des Kubernetes-Cluster korrekt geroutet und ausgewertet wird. Solltet ihr den Service noch nicht kennen und vor ähnlichen Herausforderungen stehen, schaut ihn euch gern einmal an!
Ehrlich gesagt haben wir am Ende doch mehr als nur eine einzige API. Genau genommen sind es zwei — einmal private und einmal public. Die Public-API ist die Grundlage für t3n.de. Die Private für, nunja, private Zwecke. Wir erschlagen mit diesem Ansatz nämlich noch ein ganz anderes Problem: das der Workflows. Bedingt dadurch, dass wir viele unterschiedliche Portale haben, haben wir auch viele unterschiedliche Stellen, um Management-Aufgaben durchzuführen. Das Verwalten von Stellenanzeigen passiert im Jobs-Portal, die Verwaltung von Firmeneinträgen im Firmen-Portal usw. Wir nutzen also die Chance und bauen uns eine neue einheitliche Oberfäche, in der wir die Daten von t3n.de verwalten können. Diese Oberfläche ist auch mit React gebaut und bedient sich btw. auch an unserem UI-Baukausten storybook.t3n.de.
Wie kommen die Daten jetzt genau in den Graph rein? Eigentlich ganz einfach. Jedes Portal für sich hat eine GraphQL Schnittstelle. Hierzu haben wir eine Extension gebaut, mit der Ihr eure Flow- und Neos-CMS-Projekte einfach mit einer GraphQL Schnittstelle erweitern könnt: t3n/graphl. Wir nutzen nun MicroServices, die als eine Art Link arbeiten. Die jeweiligen MicroServices exposen wiederum zwei APIs: Eine private und eine public API. Als Backend nutzen wir das jeweilige „Alt-System”. Eine Anfrage, die an den MicroService gestellt wird, wird also entsprechend über das alte System „resolved”. Alle diese MicroServices werden nun bei Apollo Studio registriert und Apollo Studio erstellt daraus einen einzigen großen Graph. Nun können wir einen Request gegen die API machen und Daten aus allen Portalen abfragen.
Aber warum die MicroServices? Man könnte doch theoretisch auch direkt die Apps an Apollo-Studio anbinden, oder? Ja, das könnte man — aber wir wollen flexibel sein. Stellt Euch dafür einfach das Szenario vor, dass unsere Anforderungen an ein System sich so stark verändern, dass wir die Business-Logik komplett neu schreiben oder auch gegen ein SaaS-Service austauschen wollen. Wir können dann später einfach den MicroService anpassen, der seine Daten dann einfach von einem anderen System zieht. Die API „nach außen” bleibt dabei aber unangetastet. Cool, oder?
Von Template bis zum Next.JS Stack
Um ehrlich zu sein wird das Word „Template” dem kompletten React-Stack nicht mehr gerecht — mittlerweile steckt da so viel mehr drin. Nachdem wir nun aber alle Daten über eine Schnittstelle verfügbar haben, ist etwas ganz spannendes passiert: Wir könnten jederzeit jeden View in unserem neuen Stack neu bauen. Das bedeutet, dass wir die Views ganz neu denken können, ohne aber die Business-Logik anfassen zu müssen.
Über die API sind wir direkt in der Lage, alle möglichen Daten einfach (die Betonung liegt dabei auf einfach!) abzufragen und darzustellen — unabhängig davon, wo die Daten oder die Business-Logik physisch angesiedelt sind. Und damit haben wir schon mal einen riesigen Meilenstein erreicht! Einzelne Teile von t3n.de sind übrigens schon heute auf dem neuen Stack. Solltet ihr euch einmal einloggen, registrieren oder im Self-Service unterwegs sein, dann surft ihr bereits auf unseren Next.JS Stack! In der Zukunft arbeiten wir daran, dass wir auch weitere Views auf den neuen Stack migrieren, um die ganzen neuen Möglichkeiten richtig ausreizen zu können!
Wenn dir dieser Deep-Dive gefallen hat, sei gespannt auf den dritten Teil. Dort 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.
Oder juckts dich schon in den Fingern? 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/
