2020-11-20

Sulu CMS: Deep Dive by Oliver

Digitale Plattformen werden in ihren Anforderungen und in ihrer Architektur immer komplexer – ist Sulu hierfür eine gute (Headless) CMS-Alternative? In diesem Deep Dive möchte ich (Oliver Kossin, Symfony Developer) meine Erfahrungen mit dem jungen CMS teilen und eins schon mal vorab setzen: Ja, Sulu ist für mich die optimale Lösung, die die User Experience mit der Developer Experience vereint. Ich bin überzeugt davon, dass dieses CMS sowohl für Developer als auch für Marketer etc. extrem spannend ist. Und Sulu wird für dich spätestens dann interessant, wenn aktuell das Thema Personalisierung und Smart Content bei dir auf dem Tisch liegt.

Zurück zur Übersicht
Tech

Sulu Blocks und Snippets am Beispiel Tchibo mobil
SULU CMS: DEEP DIVE BY OLIVER

EINE LÖSUNG, DIE MARKETER UND DEVELOPER GLÜCKLICH MACHT

„Sulu“, „Headless“, „Symfony“ – diese bereits gefallenen Begriffe sind für die einen täglich Brot, für die anderen völliger Tech-Dschungel. Je nachdem, wessen Augen grade über meinen Artikel fliegen, denkst du entweder: „Okay als Symfony Developer für mich sehr spannend. Erzähl mir von deinen Erfahrungen!“ oder aber „Hol mich bitte kurz ab – warum sollte ich jetzt weiterlesen?“

Aber gern: Dranbleiben lohnt sich, wenn du vor einem digitalen Projekt mit folgenden Anforderungen stehst – oder dich generell für neue Lösungen und Möglichkeiten in diesem Bereich interessierst:

  • Komplexe digitale Plattformen mit unterschiedlichen Seitentypen und Designs (quasi das absolute Gegenteil von OnePagern)
  • Komplexe digitale Plattformen mit unterschiedlichen Bereichen und Nutzergruppen (wie z.B. Corporate Sites mit einer Karriereseite oder einem Blog, in dem verschiedene Redakteure arbeiten, die unterschiedliche Berechtigungen haben sollten)
  • Multilinguale Plattformen

Ich setze im Folgenden erst einmal die Marketingbrille auf und beschreibe, welche Vorteile eine (Headless) Lösung mit Sulu für deinen Endkunden bringen kann. Anschließend nehme ich wieder die Entwicklerseite ein und dokumentiere meine bisherigen Erfahrungen mit Sulu.

Lies also hier erst einmal, was ein Headless System allgemein und mit Sulu für jemanden ausmacht, der seine Kunden glücklich machen will:

THE MARKETERS’ SIDE: BESTE USER EXPERIENCE MIT PERSONALISIERTEN INHALTEN & CO.

Das ist eigentlich nichts Neues: Traditionelle CMS wurden entwickelt, um Content auf dem Desktop darzustellen. Doch wir wissen, dass die Realität heute anders aussieht: Wir konsumieren Inhalte auf dem Smart Phone, via App, auf Tablets oder Smart Watches. Wir kommunizieren mit Voice Assistants und Chatbots. Es liegt also auf der Hand, dass wir neue CMS-Lösungen brauchen, die diese Flexibilität mitgehen und Inhalte devicespezifisch ausspielen können. Hier kommt Headless ins Spiel.

Headless – was bedeutet das?

Wie es der Begriff schon sagt, wird das CMS kopflos, da es vom Frontend entkoppelt wird. Der Vorteil hierbei ist immens. Die gesamte Businesslogik, zu der u.a. Prozesse wie die Validierung und Serialisierung von Daten, das Handling von Sessions etc. gehört, bleibt innerhalb der Backend-Architektur erhalten. Und es dient eine API als Datenquelle, die trotzdem für völlig verschiedene Plattformen und Devices funktioniert. Gerade hier tritt Sulu auf den Plan, da das Open Source CMS flexibel erweiterbar ist, um auch sehr komplizierte Business-Logiken abzubilden, wie etwa das individuelle Ausspielen von Daten für verschiedene Nutzergruppen. Ein Beispiel?

Eine Datenbasis für unterschiedliche Nutzergruppen

Ihr habt eine Plattform für die Kundenberater eines Unternehmens, die auch von den Endkunden genutzt werden soll – aber natürlich sollen die Endkunden andere Inhalte sehen als die Kundenberater. Der Content muss dynamisch bzw. zielgruppenspezifisch verwaltet werden können. Das Endprodukt: Ein flexibles, webbasiertes Portal, das Kundenberater als Basis für ihre Arbeit im Service Center nutzen können und gleichzeitig Endkunden bequem und übersichtlich alle Informationen zu ihren beispielsweise Mitglieds- oder Vertragsdaten bereitstellt.

Bei Projekten, in denen das Thema Individualisierung bzw. Personalisierung so im Fokus steht wie z. B. bei unserem Kunden Tchibo mobil, ist Sulu für mich die optimale Plattform – nicht zuletzt auch deswegen, da der Entwicklungsansatz des CMS sehr design-driven ist. Heißt: Es wurde viel darauf Wert gelegt, die Nutzeroberfläche trotz komplizierter Datenlogiken klar und verständlich zu gestalten, so dass Redakteure und Content Teams das CMS easy bedienen können. Auch Entwickler profitieren von diesem Ansatz. Aber dazu im Folgenden mehr.

THE DEVELOPERS‘ SIDE: WER SYMFONY KANN, KANN AUCH SULU

Für mich als eingefleischter Symfony Backend Developer gibt es natürlich ein Totschlagargument: Sulu ist eine Full-Stack Symfony Applikation – das heißt: Symfony Developer können Sulu auf die erste Sekunde. Schon mal ziemlich angenehm!

Was mich aber von der ersten Sekunde an fasziniert hat – und da kommen wir zum design-driven Ansatz von eben – ist es, mit einem klaren, strukturierten Code zu arbeiten UND damit komplexe Multiplattform-Funktionalitäten bereitzustellen.

Flexible Lösung für komplexe Anforderungen: Kacheln und dynamische Grids

Eine wichtige Anforderung in komplexen Portalen ist es, Elemente lediglich an einer zentralen Stelle pflegen zu müssen und diese frei auf der gesamten Plattform wiederverwenden zu können. Man könnte fast von einem Homepage-Baukasten sprechen – nur noch einen Schritt komplexer. Diese Anforderung können wir bei Sulu mit der Technik der „Snippets“ umsetzen. Vorteil hierbei ist es, dass ein Snippet – also ein Auschnitt der Seite –  einmal zentral angelegt werden und anschließend überall wiederverwendet werden kann, und zwar via „snippet_selection“.

Das Layout von unserem Kunden Tchibo mobil beispielsweise setzte auf ein kachelartiges Design, daher haben wir auch die Separierung “Kacheln” genannt. Diese Art von Kapselung brachte nicht nur für die Pflege Vorteile, sie konnte ebenso im Frontend eingesetzt werden und ermöglichte so eine flexible und modulare Entwicklung – beispielsweise konnte ein Entwickler das Modul “Teaser” bauen und ein anderer das Modul “Fußnoten”. Anschließend wurden die Kacheln innerhalb eines klassischen Seitentemplates im CMS verlinkt.

Dieses Vorgehen unter dem gewählten Headless-Ansatz brachte nun zunächst ein Problem mit: Wie sollte die Anordnung der Kacheln für das Frontend angegeben und ausgegeben werden? Denn, wie schon bereits erwähnt: Das Design des Portals ist kachelorientiert. Allerdings geht nicht jede Kachel über eine volle Breite. So gab es Kacheln, die nur 1/3 der Breite ausfüllen und manche, die die Hälfte befüllten. Und die Anordnung konnte komplett willkürlich sein.

Gehen wir an dieser Stelle einmal zurück zur snippet selection: Diese ist üblicherweise zunächst lediglich eine Liste. Auf jedem Seitentemplate lediglich eine snippet selection einzubinden, in welche dann die Kacheln gezogen werden können, würde zwar funktionieren, aber einen sehr geringen Grad an Konfiguration mit sich bringen. Man könnte lediglich die Reihenfolge – nicht aber eine genaue Anordnung verwalten.

Um nicht nur Kacheln zu definieren, die immer über eine volle Breite innerhalb der Templates gehen würden (oder eine fest zugeschriebene Breite haben), haben wir uns für eine deutlich innovativere und dynamischere Lösung entschieden – und mithilfe der „Block“-Komponente einzelne Reihen (Rows) im Design abgebildet, in welche sich wiederum snippet selection befinden. So war es möglich, über die Art der Blockstruktur die Breite der Kacheln abzubilden und sogar gänzlich komplette Reihen zu verschieben – aber dennoch nur die einzelnen Snippets individuell pflegen und verändern zu können.

Skizzierter Aufbau des Sulu Core.

Werfen wir nun im Folgenden noch einen Blick auf die Vorteile im Frontend.

 

Durch Headless Setup im Frontend flexibel mit Angular, react & Co.

Übergreifend können wir zunächst einmal festhalten, dass eine Headless Architektur deutlich auf die Performance einer Seite einspielt. Wie das? Schauen wir uns dafür einmal an, worin sich eine Headless Applikation von einer Applikation unterscheidet, die beispielsweise voll auf serverseitiges Rendering setzt: Nun, grundlegend erst einmal in ihrem generellen Aufbau bzw. in ihrem gesamten Ablauf. Gehen wir hier z. B einmal von einer contentlastigen Website eines Unternehmens aus, die aus vielen Bereichen besteht – einem Instagram Feed, einem Newsfeed, diversen Stellenanzeigen und eventuell auch Projektreferenzen. All diese Elemente müssen vollständig vom Server geladen und gerendert werden, bevor diese an den Browser gesendet werden. Das heißt: Der Browser wartet immer auf die vollständige Seite. Ähnlich wie bei einem PDF-Abzug eines geschriebenen Texts. Man kann zwar mehrere Versionen erstellen, aber die PDF besteht immer aus dem gesamten Text.

Headless setzt im Frontend nun auf einen ganz anderen Ansatz. Zwar muss auch hier die Website an den Browser geschickt werden, jedoch besteht sie jetzt aus einer ganz eigenen Applikation. Statt nur eine HTML-Site zu downloaden, laden wir beim initialen Aufruf nun beispielsweise eine Angular-geschriebene Applikation runter. Welchen Vorteil hat das? Kommen wir dafür noch mal auf das Beispiel der verschiedenen Feeds zurück bzw. auf eine Site, die aus mehreren Feeds besteht. Was machen wir, wenn einer der Feeds nicht verfügbar ist? Bei serverseitigem Rendering hätten wir ein deutlich größeres Problem. Denn: Entweder würde die gesamte Seite ewig laden (da alle schon geladenen Feeds auf die Vollendung des letzten warten) oder der Feed würde einfach ganz leer bleiben. In einem Headless Setup kann die Applikation viel besser auf die jeweils eigenen Komponenten eingehen.

So wird z. B. jeder oben genannte Feed einzeln angesprochen und geladen. Auch wenn manche Module langsamer laden als andere, würde der User schon Content sehen, ohne auf das Laden der ganzen Site warten zu müssen. Das gleiche würde für generelle Elemente einer Seite wie etwa auch Routen gelten.

Und das Schöne dabei: Welche Technologie am Ende im Frontend genutzt wird, ist dem Frontend Developer völlig freigestellt. So kann beispielsweise die Website in React, die Android App in C# oder die iOs App in Swift geschrieben sein, ohne dass es für das CMS einen Unterschied macht.

FAZIT: SULU SORGT FÜR BESTE UX & DX

Wenn du bis hierhin durchgehalten hast, bist du sicher bei mir, wenn ich sage: Das Open Source Framework ist vor allem bei komplexeren Projekten eine sehr effiziente Option. Eine Single-Page Applikation, die mit einem klaren Code komplexe Businesslogiken abbilden und gleichzeitig eine intuitive Benutzeroberfläche bieten kann – einfach wie gemacht für das Ausspielen von personalisiertem, dynamischem und interaktivem Content on demand. Wir können das in unseren bisherigen Erfahrungen nur bestätigen.

Noch Fragen zu Sulu, Symfony oder Headless Architekturen?

folge uns auf:
FRISCHE BRISE FÜR DEIN POSTFACH
Wir informieren dich monatlich über digitale Trendthemen, neue Technologien, spannende Projekte und aktuelle Jobs bei der brandung. Lass dich erfrischen!