Ich habe diese Woche auf der enterJS in Darmstadt einen Vortrag gehalten. “React & Redux: Skalierbar bleiben - auch in komplexen Architekturen.” Der Kern meines Arguments lässt sich in einem Satz zusammenfassen: Architektur passiert immer. Die Frage ist nur, ob bewusst oder aus Versehen.
In einer Todo-App merkt man den Unterschied nicht. Da kann der Code aussehen wie er will, es funktioniert trotzdem. Aber in einem echten Projekt - mit einem großem Team, harten Deadlines, echtem Geld - wird jede architektonische Nicht-Entscheidung irgendwann zur Altlast.
Was mich zu dem Vortrag gebracht hat
Seit über einem Jahr baue ich mit meinem Team bei nexum eine E-Commerce-Plattform für Microspot, einen der größten Schweizer Online-Händler. React und Redux als Frontend, SAP Hybris als Backend, komplett headless über APIs angebunden. React ist zu diesem Zeitpunkt noch jung als Wahl für so ein Projekt. Redux erst recht. Headless Commerce ist kein etabliertes Pattern, sondern Neuland.
Die Frage, die sich früh stellte: Wie muss der Code organisiert sein, damit das Team mitwachsen kann, ohne dass alles langsamer wird?
Was bewusste Architektur ermöglicht
Redux gibt einem ein Modell für Datenfluss. Aber Redux sagt einem nicht, wie man einen Store schneidet, wenn acht Leute parallel an Features arbeiten. Das muss man selbst entscheiden. Und zwar früh.
Wir haben den Store nach fachlichen Domänen aufgeteilt. Suche, Produkt, Warenkorb, Checkout - jede Domäne besitzt ihren Teil vom State, ihre Actions, ihre Reducer. Nicht weil das im Tutorial so stand, sondern weil wir wollten, dass ein Entwickler am Checkout arbeiten kann, ohne die Suche zu verstehen. Dass ein neuer Kollege in einer Domäne produktiv wird, ohne den ganzen Store im Kopf haben zu müssen.
Dazu eine saubere Abstraktionsschicht gegen Hybris. SAP Hybris liefert tief verschachtelte Datenstrukturen, die kein Mensch direkt in Komponenten verdrahten will. Also haben wir normalisiert und entkoppelt, damit die UI nicht wissen muss, woher ihre Daten kommen.
Das klingt nach offensichtlichen Entscheidungen. Ist es im Nachhinein auch. Aber genau das ist der Punkt: Diese Entscheidungen muss man bewusst treffen. Architektur passiert nämlich so oder so. Wenn man sie nicht aktiv gestaltet, wächst sie trotzdem - nur eben in eine Richtung, die niemand gewählt hat. Und in kleinen Projekten fällt das nicht auf, weil alles noch in einen Kopf passt. Erst wenn das Team wächst, wird sichtbar, welche Architektur man sich eigentlich gebaut hat.
Es kommt nicht drauf an “benutzt React” oder “benutzt Redux”. Sondern: Die Wahl des Frameworks ist zweitrangig. Entscheidend ist, ob man sich hinsetzt und über Struktur nachdenkt, bevor die Struktur über einen nachdenkt.
Abseits des Vortrags war die enterJS einfach eine gute Konferenz. Nette Leute, ehrliche Gespräche beim Speaker-Dinner am Vorabend, guter Austausch in den Pausen.