Modularisierung von Frontends mit NitroNet for Sitecore

„Wenn die Chemie stimmt, gibt es auch mit der Physik keine Probleme“ so ein bekanntes Sprichwort von Dr. Fritz P. Rinnhofer. Die Chemie zwischen Menschen muss also stimmen. In unseren Sitecore Projekten haben wir einige Rollen, die letztendlich bei der Geburt einer Webseite beteiligt sind. Aus Sicht der Implementierung bringen dabei zwei entscheidende Rollen „Frontend“ und „Backend“ ihre Expertisen ein.

Der Frontend’ler, Magier des HTML, CSS und Javascripts, dessen Lifestyle zwischen Design, Ästhetik und User Experience spielt, arbeitet mit dem sogenannten Backend’ler zusammen. Dieser, welcher im Gegenzug mit Daten jongliert, strukturiert, erhebt und die Logik der Präsentation über gewiefte Algorithmen zur Verfügung stellt, ist für die Leistung und Abläufe im Hintergrund zuständig. Wie wir also erkennen, haben hier zwei verschiedene Disziplinen, welche eine eigene Expertise besitzen. Beide Charakteren, so verschieden sie auch sind, sprechen letztendlich in der gleichen Sprache miteinander – auch wenn ihr Blickwinkel jeweils verschieden ist. Wie kommt nun aber eine Webseite letztendlich zusammen und wie werden diese beiden Bauteile zusammengesteckt, sodass sie harmonisch miteinander funktionieren? Genau diese Fragestellung stellt sich früher oder später jedes professionelle (Entwicklungs-)Team.

Das Leben vor ein paar Jahren

Vor geraumer Zeit entwickelten unsere Frontend’ler fertige Webseiten, welche das ganze Verhalten bereits inne hatten. Befüllt mit Beispielinhalten und keinem Verwaltungssystem im Hintergrund. Eine schöne Hülle zum interagieren – leider seelenlos. Diese Hülle diente uns und unseren Kunden das Verhalten direkt im Browser anzuschauen und ein wenig „herumzuspielen“. Konzepte welche funktionierten wurden abgenommen, andere nochmals überarbeitet. Solange bis die Kundenanforderungen erfüllt wurden. Aus diesem Grund nannten wir dieses Zwischenprodukt „Frontend-Prototyp“, auch wenn aus Frontend-Sicht der Begriff „Prototyp“ verpönt erschien, war er aus Konzept-Sicht erst ein einzelner Baustein des ganzen Konstrukts. Sobald dies vollendet wurde, startete das Backend-Team mit der Integration des Frontendes. Das Layout wurde erstellt, CSS und Javascript integriert und die Markup-Dateien in eine systemeigene Sprache übernommen. In Sitecore arbeiten wir seit längerem ausschliesslich mit dem ASP.Net MVC Muster, welches voraussetzt, dass die HTML-Dateien des Frontendes in die View-Engine von .Net (*.cshtml Dateien) integriert wird. Textbausteine, welche durch das WCMS gepflegt werden sollten, benötigen eine Dynamisierung, natürlich schön in Models gekapselt und zusammen mit einer logischen Verwaltungsstruktur im Hintergrund zum Leben gebracht. Das Frontend bekommt somit seine verdiente Seele. Der Charakter formt sich mit jedem Sprint bis zum Projektabschluss.

Dieses Vorgehen scheint strukturiert zu sein. Erfüllte jedoch nicht unseren Bedarf und unsere Qualitätsansprüche. Der Nachteil lag nämlich genau bei dieser harten, manuellen Trennung. Was geschieht, wenn das Frontend im Nachhinein angepasst werden sollte oder der Backend’ler eine kreative Minute hatte und das Markup erweiterte, um seine Ansprüche der WCMS-Modularisierung gerecht zu werden? Oftmals wurde nur eine Seite der Münze angepasst, die Überführung zurück ins Frontend bzw. andersrum wurde im Eifer des Gefechtes oftmals vergessen. Resultierend kamen zwei (leicht) verschiedene Versionen heraus. Das Testen des Frontend-Prototypes und dessen Qualität konnte keine Aussage mehr über die Qualität des Endproduktes liefern. Diese beiden Schienen wurden ja durch eine manuelle Überführung unterbrochen. Wartbarkeit und Transportierfähigkeit der Lösung wurden so nahezu eliminiert. Der Status-Quo des Anfangs konnte nur über eine manuelle Bereinigung und Angleichung wiederhergestellt werden. Aufwände, die wir heute als unnötig erachten können.

Wie wir jetzt Frontend entwickeln

Wie gehen wir heute mit dieser Problematik um? Diese Frage beschäftigte uns als Digital Agentur die letzten zwei Jahre sehr stark. Frontend und Backend müssen eine engere Bindung bekommen, obwohl andere Grundtechnologien dahinter stecken. Wir wollen unseren Kunden eine effizientere und qualitativ bessere Lösung bieten können. Aus dieser Anforderung heraus entwickelten einige exzellente Entwickler rund um Ernscht, Röbi und Remo ein neues Werkzeug für unseren Frontend Stack, Nitro!

Nitro, ein OpenSource Produkt für die Erstellung von Frontend-Applikationen präsentiert sich wie auf Git-Hub wie folgt:

Nitro is a Node.js application for simple and complex frontend development with a tiny footprint.
It provides a proven but flexible structure to develop your frontend code, even in a large team.
Keep track of your code with a modularized frontend. This app and the suggested atomic design and BEM concepts could help.
Nitro is simple, fast and flexible. It works on OSX, Windows and Linux. Use this app for all your frontend work.

Mit diesem Grundbaustein für unsere Frontend-Entwicklung gehen wir für uns neue Wege mit folgendem elementaren Unterschied zu vorher:

  1. Frontend ist nicht mehr nur eine modulare Form von „HTML, CSS und Javascript“ – es berücksichtigt explizit die Trennung zwischen Darstellung und Daten
  2. Die Modularisierung wurde gemäss dem Design Pattern „Atomic Design“ strukturiert, welches die Wiederverwendung von bestehenden Elementen ganz klar strukturiert

Nitro: Trennung zwischen Darstellung Daten

Dieser Ansatz führt zu einer natürlichen Trennung zwischen Darstellung und Daten. Kein reiner Text sollte mehr verwoben zwischen HTML-Syntax sein. Zusammen mit einer Template-Engine (Handlebars) wird diese Trennung erzwungen. Somit entsteht die Chance mit der richtigen Datenquelle eine Repräsentation darstellen zu können. Die Datenquelle verfügt über einen verständlichen Kontrakt, getrieben aus dem Frontend.

nitroNet_basic_sample

Nitro: Modularisierung by Atomic Design

Wie im Intro erwähnt, muss die Chemie stimmen, Atomic Design setzt sich sinnbildlich mit der Chemie auseinander. Das kleinste wiederverwendbare Element bekommt die Bezeichnung „Atom“, ein Element, welches eins oder mehrere Atome benötigt, wird als „Molekül“ bezeichnet. Ein Element, welches eines oder mehrere Moleküle benötigt für die Darstellung nennt sich „Organismus“. So setzt sich das Molekül „Hauptnavigation“ aus mehreren „Link“-Atomen zusammen und ist zugleich ein lebender Bestandteil des Organismus „PageHeader“.

nitroNet_Sitecore_Architecture_atomic_design

Jene Sitecore-Entwickler, die diese Kurzanleitung im Kopf nachgebildet haben, bekommen wohl fast Freudetränen in die Augen und sagen: „Ja, genau so würde ich meine Komponenten im CMS strukturieren, genau so müsste ich die Sitecore-Item-Templates erstellen.“ Und genau das ist das Wunderbare an diesem Ansatz: Das Frontend setzt sich automatisch durch diese Art von Modularisierung mit der Applikation und deren Struktur auseinander.

Zusammenspiel zwischen Frontend und Backend

Wie nun erläutert passt der Ansatz von Nitro auf die Denkweise von Sitecore und deren Komponentenstruktur sehr gut. Wie können wir aber diese Welten verbinden, wie wird das fertige Haus nun zusammengesteckt?

Um diese Frage beantworten zu können, müssen wir es schaffen, dass keine Übernahme von Frontend ins Backend mehr benötigt wird. Wir benötigen eine gemeinsame View-Engine. Durch den Einsatz der Template-Sprache Handlebars haben wir zusammen mit dem Veil-Parser ein gemeinsames Verständnis zwischen Frontend und Backend schaffen müssen und können.

nitroNet_component_sample

So entwickelte unser Fabian das auf .Net basierte Produkt „NitroNet„. NitroNet ist eine eigene View-Engine, basierend auf dem Veil-Parser und verbindet das Framework Nitro mit Sitecore als Datenlieferant. Ohne Funktionsverlust.

Somit arbeiten Frontend- und Backend-Entwickler nun an der gleichen Präsentationsschicht. Änderungen am Frontend sind direkt und unmittelbar – es wird keine Überführung mehr benötigt. Änderungen an HTML-Struktur oder Styling haben keinen Einfluss mehr auf die Backend-Entwicklung. Die gemeinsame Schnittstelle wird über das Daten-Objekt sichergestellt. Eine kleine und kontrollierbare Schnittstelle.

nitroNet_Sitecore_Architecture

Das komplette NitroNet haben wir als Folgeschritt OpenSource auf Git-Hub verfügbar gemacht. Für die Installation wurden eigene NuGet-Pakete generiert. Die Verbindung zwischen Nitro und Sitecore benötigt somit nur wenige Minuten an Installationsarbeit. Da es keine Blackbox-Lösung von uns alleine sein und bleiben soll, hoffen wir zusammen mit der Sitecore-Community einen Contributor zu finden, welcher mit uns zusammen diese Idee weiterverfolgt und -entwickelt.

Also liebe Frontend’ler, probiert doch Nitro unbedingt aus! Liebe Backend’ler, integriert das Nitro eures Kameraden in Euer Sitecore. Ihr werdet staunen und euch freuen! Mehr über diese Integration und entsprechende Installationsanleitung mit Screenshots findet ihr auf unserer Webseite www.nitronet.io.

Wenn man auf den Geschmack gekommen ist, beginnt die Sucht.“ Ein weiteres Zitat von Herrn Rinnhofer. Ich hoffe ihr werdet gleich süchtig wie wir, die Nebenwirkungen sind aktuell noch nicht bekannt, der Trip ist aber ein guter 🙂

P.S.
Bei diesem Artikel handelt es sich um den zweiten Teil einer kleinen Trilogie. Wer den Ersten verpasst hat, darf diesen gerne hier nachlesen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>