On-Demand Webinar: FirstSpirit Hybrid CMS

diva-e Vortrag

Kopflos zum Erfolg – Mit Hybridem FirstSpirit und NuxtJS zur optimalen Kundenlösung

Anhand eines konkreten Kundenprojektes zeigen wir, wie man die Vorteile von Hybridem FristSpirit in der Praxis nutzt, um eine moderne und komfortabel pflegbare Webseite zu realisieren. Wir erläutern unsere Systemarchitektur und erklären die grundlegenden Bausteine unseres Ansatzes. Nicht zuletzt gibt es die entstandene Lösung natürlich auch zu sehen.

Transkript zum Webinar: FirstSpirit Hybrid CMS

Vorstellung

Angela Meyer: Herzlich willkommen zu unserem heutigen diva-e Webinar mit unserem Partner e-Spirit. Heute zeigen unsere Experten, wie Sie in diesen Zeiten die beste Entscheidung treffen für ein Content-Management-System beziehungsweise eine Digital Experience Cloud. Das Webinar ist in zwei Parts aufgeteilt. Zunächst startet Tim Rother von e-Spirit mit seinem Vortrag zu e-Spirits FirstSpirit Hybrid CMS, „Being prepared for what the Future brings“. Und danach beantworten wir Ihre ersten Zwischenfragen. Und daraufhin folgt Niklas Krauth von diva-e mit seinem Vortrag „Kopflos zum Erfolg mit hybridem FirstSpirit“ und Nuxt GS zur optimalen Kundenlösung. Ich freue mich, dass ihr heute mit dabei seid. (5 Sek.) Wir starten mit einem kleinen Technik-Check. Rechts von Ihnen befindet sich eine Bedienpanel mit einer Frage Box. Und es wäre super, wenn Sie jetzt ein kurzes Zeichen geben würden, ein Hallo reinschreiben, damit wir auch prüfen können, ob die Technik funktioniert. Das sieht sehr gut aus. Viele Hallos, Hey, Sie freuen sich auf das Webinar. Es funktioniert, die Technik läuft, dann würde ich sagen, können wir jetzt dann auch mit dem Inhalt starten beziehungsweise mit einer kurzen Vorstellungsrunde unsererseits beziehungsweise von mir erstmal. Mein Name ist Angela Meyer und ich bin im diva-e Marketingteam seit rund vier Jahren und betreue die Webinare und bin heute eure Moderatorin. Genau, jetzt würde ich mal das Wort an Tim weitergeben, der sich auch kurz vorstellen kann.

Tim Rother: Ja, herzlich willkommen auch von meiner Seite. Ich bin Tim, bei e-Spirit Produktmanager im Bereich globale Produktstrategie. Vom Background her bin ich kein echter ITler, sondern habe seit kurzem einen MBA im Bereich digital Business. Und habe vorher relativ lange im Bereich Produktmanagement, Projektmanagement und Vertrieb gearbeitet, im Bereich produzierendes Gewerbe. Bin jetzt schon ein bisschen was dabei bei e-Spirit und freue mich riesig auf das Webinar heute mit unserm Power diva-e.

Angela Meyer: Sehr schön, danke Tim. Ja Niklas, noch ein paar Worte zu dir.

Niklas Krauth: Ja, hallo erstmal von meiner Seite. Mein Name ist Niklas Krauth, ich bin Softwarearchitekt bei der diva-e mit, ja, Schwerpunkten eigentlich auf Webanwendungen, wozu unter jetzt auch hier dieses CMS Thema Fail Finding, Frontendthemen und davor auch schon länger in der Softwareentwicklung und Softwarearchitektur B2B, B2C unterwegs. Ihr könnt mich leider heute nicht sehen, weil ich in Ermangelung eines go to Meeting Linux Clients nur per Handy dabei bin, sorry dafür.

Angela Meyer: Das bekommen wir auch so hin. Ja, dann würde ich sagen, ja, dann würde ich sagen, Tim du startest nun mit deinem ersten Teil zum Thema FirstSpirit.

Das FirstSpirit Hybrid CMS

Tim Rother: Okay, dann hoffe ich erstmal, dass ihr alle meinen Bildschirm seht? Und ich wiederhole nochmal die Danksagung auch gerne für die Einladung hier zu dem Webinar, dass wir heute hier uns als e-Spirit an dem Webinar beteiligen können. Und ich begrüße natürlich auch alle Interessierten, die vermutlich im Homeoffice oder wo auch immer ihr gerade unterwegs seid, die sich heute Nachmittag eingewählt haben. Und meine, ja, zirka 20 Minuten werde ich dafür verwenden, euch FirstSpirit Hybrid CMS näherzubringen, mit dem Ziel, dass ihr am Ende alles wisst, Bescheid wisst, warum FirstSpirit Hybrid CMS das Content-Managementsystem der Wahl ist und euch zukunftssicher in die nächsten Jahre begleiten kann. Das ist also auch gleich der Titel Being prepared for what the Future brings. Und die 20 Minuten möchte ich im Detail, wenn man bei 20 Minuten von wirklichen Details sprechen kann, mit einer ganz kurzen Einführung von e-Spirit über das Unternehmen nochmal nutzen. Aber der Hauptfokus dann natürlich sehr schnell darauf, auf Hybrid CMS. Was ist das und warum brauche ich es? Genauso dann ein bisschen das Thema High Level Architektur, FirstSpirit Hybrid CMS euch näherzubringen für die Details. An der Stelle wird die Zeit heute nicht reichen, aber das können wir gerne im Nachgang dann noch ein bisschen auch tun. Und da es ja auch ein Entwickler-fokussiertes Webinar ist, natürlich auch what's in it for me? Also was bringt mir FirstSpirit als Entwickler und warum ist das hybride CMS auch für mich als Entwickler gut? Zu mir haben wir schon genug gesagt in der Vorstellung. Das einzige vielleicht unten nochmal meine E-Mail-Adresse, für diejenigen, die im Plenum die Fragen nicht stellen wollen. Oder, wenn nochmal bei einer Nacht darüber schlafen euch noch Ideen kommen, einfach gerne im Nachgang dann auch nochmal melden. Ja, kommen wir ganz kurz zu der Vorstellung von e-Spirit als Unternehmen.

Über e-Spirit

Wir sind eines der führenden Content-Managementsystemhersteller und bereits seit etwas über 20 Jahren jetzt auf dem Markt, haben also im letzten Jahr 20. Geburtstag gefeiert, haben unseren Hauptstandort in Dortmund und einen zweiten großen Standort in Boston, in den USA. Und auch seit letztem Jahr in Apec, also sprich in Singapur und in Oakland, ja, jeweils Vertretungen, die den lokalen Markt dort vor Ort bedienen. Unsere Kunde sind breit gefächert. Wir haben also in den über 20 Jahren über 10.000 verschiedene Projekte für über 1.000 verschiedene Kunden gemacht und ich habe euch eine kleine Auswahl der Kunden mal hier mitgebracht. Wobei es hier gar nicht so wichtig ist, welche Namen da unbedingt stehen. Ihr werdet vermutlich den einen oder anderen auch wiedererkennen. Die Message, die ich hier senden möchte, ist, es ist eigentlich völlig egal in welcher Branche oder in welchem Wirtschaftszweig ihr unterwegs seid. Wir als e-Spirit, wir kennen uns überall aus, ja. Sei es im Bereich der öffentlichen Hand oder produzierendes Gewerbe, Banking oder auch E-Commerce, wo wir mit unseren Premiumpartnern Salesforce, SAP und auch Spica, um mal drei zu nennen, sehr erfolgreiche zusammen mit Partnern auch unsere Kunden bedienen. Ja, die Folie habe ich mitgebracht, nicht, um euch zu erschrecken. Das ist eher so ein bisschen was für den Nachgang, für das Handout. Aber es ist aus meiner Sicht ein ganz gelungener Versuch, einmal die Highlight-Features unserer Software von FirstSpirit auf eine Folie zu bringen. Und ich möchte hier auch gar nicht wirklich näher darauf eingehen. Den einzigen Tipp, den ich euch geben möchte, ist, von innen nach außen, dann ergibt das Ganze auch Sinn und dann könnt ihr euch im Nachgang nochmal damit eher auseinandersetzen. Weil wirklich im Detail darauf einzugehen, das würde die 20 Minuten hier und heute definitiv sprengen. Denn ich möchte euch ja eher ein bisschen was zum Thema Hybrid oder hybrides CMS erzählen und warum brauchen wir das überhaupt?

Das hybride CMS und wofür wir es brauchen

Denn es gibt ja Headless Systeme, es gibt die traditionellen, monolithischen Systeme und was ist dann überhaupt hybrides CMS und wofür brauchen wir das dann überhaupt? Um dieser Frage auf den Grund zu gehen, möchte ich mit dem Begriff Vuca beginnen. Vuca ist seit, ja, so zirka eineinhalb Jahren, was durch die Geschäftswelt geistert und in vielen Bereichen auch noch nicht so richtig angekommen ist. Oder jetzt, gerade auch durch die Situation, die jetzt entstanden ist, dass wir alle zu Hause sitzen, keiner so richtig weiß, wie es vielleicht in zwei Wochen weitergeht, nochmal eine ganz neue Bedeutung erfährt. Vuca, was bedeutet das? Die Begriffe stehen unten runter, aber nochmal zu einer ganz kurzen Erklärung. Also die sowohl Aktivität, es geht immer schneller rauf und es geht immer schneller runter. Es gibt Trends, die kommen und gehen in einer nie dagewesenen Geschwindigkeit, was wiederum zu einer gewissen Unsicherheit führt. Mache ich das richtige? Was kommt als Nächstes? Entscheide ich auch das richtig? Es wird viel von destruktiven Technologien gesprochen. Was bedeutet das für mich als Unternehmen? Ja und ganz aktuell sicherlich auch für jeden einzelnen privat das Thema Unsicherheit. Wann kann ich wieder Verwandte besuchen? Ja, also diese Unsicherheit ist mittlerweile allgegenwärtig. Die Unsicherheit hängt aber auch wieder eng an der Komplexität. Die Welt wird immer komplexer, ist in den Jahren immer komplexer geworden und es gibt keine einfachen Entscheidungen mehr. Dadurch, dass alles so ineinander verwoben und vernetzt ist, haben selbst kleine oder können selbst kleine Entscheidungen größere Auswirkungen habe, die ich heute noch gar nicht überblicken kann.

Und dass, obwohl immer mehr Entscheidungen auch datengetrieben getroffen werden. Da kommt dann die Ambiguität ins Spiel, diese Mehrdeutigkeit auch. Und die Interpretationsspielräume, die mir auch Daten liefern, sind auch in ungeahnten Größen gestiegen, sodass das wiederum zu einer zusätzlichen Unsicherheit führt. Und das verlangt eigentlich fast danach, dass die Menschen sich nach Sicherheit sehnen, nach etwas Vorhersehbarem sehnen. Das ist die eine Seite der Medaille. Auf der anderen Seite und da versetzt sich jetzt jeder mal vielleicht in die eigene Lage als Kunde, wollen wir immer mehr, mehr, mehr, mehr. So, wir wollen über immer mehr Kanäle erreichbar sein. Ich möchte mein Alexa fragen. Wie wird das Wetter morgen? Und möchte nicht aufstehen und mein Tablet suchen. Also ich bin über immer mehr Kanäle erreichbar, auf mobile Art, auf Voice. Ich möchte relevanten Content bekommen. Ich möchte also auf mich zugeschnittene, personalisierte Informationen bekommen und nicht mit irgendwas zugeschüttet werden. Und das erzeugt ganz einfach gewisse Spannungen, auf der einen Seite der Wunsch, diese Unsicherheiten, der Wunsch nach Sicherheit und auf der anderen Seite dieses immer mehr, mehr, mehr. Was bis heute weder ein Q-Headless-CMS, noch ein traditionelles monolithisches CMS so wirklich bewerkstelligen kann.

Denn diese ganzen Herausforderungen, gerade das mehr, mehr, mehr verlangt natürlich auch von Unternehmen eine neue Flexibilität und auch Automatisierung in Abläufen, um den ganzen zusätzlichen Inhalten, die bereitgestellt werden müssen, überhaupt Herr zu werden. Das ist mal die, ich sage mal, die High Level Sicht. Wenn ich jetzt ein Stück tiefer gehe und das mal auf Unternehmensebene betrachte, auch dort gibt es diese zwei Welten. Ich habe das hier mal anhand eines Spektrums so ein bisschen aufgemalt und jeder von euch kennt mit Sicherheit dieser Spannungen, die entstehen.

Auf der einen Seite gibt es Menschen, die nicht despektierlich gesagt, vielleicht so ein bisschen die ewig Gestrigen, ja. Die sich gerne an den Dingen halten, die sie kennen, die sich, die nicht so aufgeschlossen gegenüber neuen Dingen sind, die mit dem zufrieden sind, was sie gerade haben und was sie tun. Und auf der anderen Seite gibt es dann die Leute, die jeder neuen Technologie hinterherrennen, die auf das neueste Pferd setzen und die dabei richtig Spaß haben, auch in, ja, verschiedene Dinge einfach mal auszutesten. Und mich würde es nicht überraschen, wenn das in einigen Unternehmen vielleicht auch so aussieht. Das heißt, es gibt nicht nur die Leute, die sich eher rechts bewegen oder eher links. Sondern vielleicht auch, dass das Marketing super innovativ unterwegs ist, die Redakteure aber so ein bisschen, ja, eher zurückhaltend sind, was die neuen Technologien angeht. Und dann wiederum im Bereich der Developer, das ist jetzt auch typisch mit dem Headless CMS, wo die neuesten Technologien eingesetzt werden sollen, wo man Spaß daran hat, mit modernen Dingen zu arbeiten. Und auch hier entsteht ein natürliches Spannungsfeld, das erzeugt Reibung. Weil man untereinander sich vielleicht nicht versteht und auch gar nicht so richtig weiß, was möchte der Andere denn jetzt von mir? Und dafür bieten wir von e-Spirit mit FirstSpirit, mit unserem Hybrid CMS die Lösung, indem wir ein modernes, zukunftssicheres CMS geschaffen haben, was alle Bereiche abdeckt. Ja, auf der einen Seite das Sicherheitsbedürfnis von den Leuten, die gerne eine Konstante haben, die gerne mit dem Gewohnten arbeiten und gewohnten Umgebungen zu tun haben. Aber auch gleichzeitig zukunftsorientiert die neuesten Technologien einsetzt, Microservice basiert, Microservice basiertes arbeiten und die Erweiterbarkeit und Skalierbarkeit für zukünftige Kundenanforderungen. Wir haben ja gelernt, die Kunden möchten immer mehr, es kommt immer mehr dazu. Und auch hier die Erweiterbarkeit und die hohe Integrationsfähigkeit von FirstSpirit, für andere Systeme oder in andere System, haben ein modernes und zukunftsfähiges CMS erschaffen. Es gibt aber noch eine dritte Ebene. Also wir hatten das High Level, dann die Unternehmensebene und, wenn wir jetzt so ein bisschen nochmal auf Headless und traditionelle Systeme eingehen. Warum stehen die sich eigentlich so ein bisschen gegenüber? Habe ich mir mal ein paar Vorteile von Headless Systemen rausgesucht.

Vorteile von Headless-Systemen

Mit Headless ist man viel agiler. Man ist mehrkanalfähig, das heißt, ich kann sowohl auf meine Webseite was aufspielen, aber ich kann diesen Inhalt auch benutzen, um das Ganze in einer mobilen App oder über Alexa oder auch einen Backofen auszuspielen, also auch IOT-friendly. Das sind so die Business Usecases. Für Micha, als Entwickler, bedeutet das aber, ich habe Frameworks, die ich benutzen kann. Ich kann neueste Technologien verwenden und ich brauche kein spezifisches CMS Knowhow. Also ich kann mich wirklich um das Frontend kümmern und muss nicht noch gucken, welche Arbeiten da im Backend anfallen. Auf der anderen Seite, die eher, ja, ich nenne sie eher traditionellen Content Managementsysteme, haben eine gewisse Einfachheit in der Bedienung, sind immer previous based, vorschaubasiertes Arbeiten, was natürlich für einen Redakteur super wichtig ist. Damit er weiß, wie sieht der Inhalt aus, der ausgespielt wird? Und diese sogenannten Enterprise Capabilities. An der Stelle mal genannt Multi-Language oder Multi-Side, das heißt für Großunternehmen die Herausforderung. Wie manage ich meinen Content, der in der ganzen Welt verteilt ist? Oder auch Formularmanagement oder Rechtemanagement, das heißt, welcher Benutzer darf in meinem System was? Mehrstufige Workflows für Content, der kritisch ist zum Beispiel. Das sind Dinge, die im Headless nicht so ausgeprägt sind oder gar fehlen. Und auf das Thema tiefe Integration und Sicherheit komme ich im Späteren nochmal.

Man merkt aber, ich habe hier zwei Dinge, die sich irgendwie gegenüberstehen und die sich ein bisschen beißen. Und das liegt daran, dass Headless Content Managementsysteme in erster Linie für Entwickler gebaut sind, während die traditionellen Systeme immer den Schwerpunkt belegt haben auf den Nutzer. Und das ist das natürliche Spannungsfeld, von dem ich eingangs schon mal gesprochen habe, was wir mit FirstSpirit auflösen. Denn bei uns, das System verbindet auf der einen Seite die Mächtigkeit, aber gleichzeitig Einfachheit von Enterprise Class Content Managementsystem und auf der anderen Seite bietet es aber auch State of the Art, Architektur oder Headless Architektur Microservice basiert. Das heißt, ich muss mich nicht entscheiden, wenn ich jetzt bei Matrix wäre. Nehme ich jetzt die rote oder die blaue Pille? Ich darf beide nehmen und das ist der wesentliche Vorteil und der Grund, warum Hybrid CMS das zukunftssicherste CMS ist, mit dem man auch noch in den nächsten Jahren auf jeden Fall gut aufgestellt ist. (4 Sek.) So und das war der einleitende Teil, etwas globaler gehalten, mit ein bisschen Hintergrund zum Thema Hybrid.

Definition: Hybrid

Waren auch schon die einen oder anderen Erklärungen drinnen, was jetzt Hybrid bedeutet. Trotzdem möchte ich nochmal gerne anhand von zwei Beispielen erläutern, wie und warum das Ganze Hybrid heißt. Zunächst mal anhand von Integrationsplayern, durch das man-. Das ist jetzt klassische Architektur. Also es gibt ein Content Managementsystem Backend und es gibt aber auch aufgesetzt einen Content-as-a-Service, der schon aus dem Backend Daten konsumiert und eine AP bereitstellt, über die dann die unterschiedlichen Touchpoints beziehungsweise Ausgabekanäle sich die benötigten Daten, die benötigten Inhalte ziehen, um es dann zu veröffentlichen. Das ist das, was Standard bei jedem Headless Content Managementsystem ist. was bei e-Spirit ein bisschen anders ist und noch on top kommt, ist das, was ich vorhin als Tiefenintegration beschrieben habe. Das bedeutet, dass wir native Objekte für ausgewählte Kanäle erzeugen. Zum Beispiel einen Produktkatalog eines Shops im Backend bearbeiten können oder vorschaubasiert in einem System arbeiten können und dort direkt im Frontend, ja, Content bearbeiten können, obwohl die ganze Seite, ja, das ist beim Shop natürlich immer so, dass der Shop das führende System ist, also nicht CMS-geführt. Und ich habe da, mit, ja, FirstSpirit trotzdem die Möglichkeit, vorschaubasiert Inhalte zu pflegen, zu bearbeiten, zu verändern. Das ist gerade für die Benutzer ein Riesen, Riesenvorteil, den so klassische, reine Headless CMS eben nicht bieten. Und natürlich, gerade im Frontend, sind wir da ein bisschen agnostisch. Also ich muss nicht alles wegwerfen, wenn sich mal die Frontendtechnologie ändert. Es gibt noch einen zweiten Grund, weswegen das Ganze auch hybrides CMS heißt und das sind die Themen Statik und Dynamik.

Ich habe mal den klassischen statischen Weg, wie Webseiten gebaut wurden und wie es so ein bisschen auch jetzt wiederkommt. Also man hat irgendwo ein Daten Storage und hat statisch vorgenerierte und statisch generierte Webseiten. Denn das ist bis heute immer noch so, es gibt nichts Schnelleres als eine Webseite, die statisch generierte oder statisch generiertes HTML ausliefert. Ja, da kann ich auch ein bisschen Dynamik noch zupacken, wenn ich das möchte. Dann gibt es noch die Schnittstelle des Application Servers dazwischen.

Zusätzlich zu der Geschwindigkeit des statischen Systems habe ich auch noch eine Sicherheit, weil ich eben nicht mehr hier an das Backend heranmuss. Nachteil ist, es ist für Webseiten. Also ich kann relativ schwierig nämlich meiner Alexa sagen: Bitte lies mal hier das HTML raus und gib das als Sprache zurück. Deswegen gibt es den zweiten Weg, den ich vorhin schon skizziert habe, dass, dann der Headless Weg ist mit FirstSpirit, dem Content-as-a-Service für die dynamische Generierung, die dann auch dieses Thema Multi Touchpoint-Fähigkeit hat. Übrigens der Weg HTML statisch rausgeneriert erfährt gerade so ein bisschen eine Renaissance. Wenn man sich das Thema Jamstack nochmal anschaut, das ist der Versuch auch von Headless Anbietern, auch von reinen Headless Anbietern, die dynamisch erzeugten Inhalte wieder zu statifizieren. Das kommt bei dem Hybrid CMS von e-Spirit, out of the Box, habe ich beide Möglichkeiten. Und das ist mal ein Beispiel einer Website, wie sie aussehen kann. Das heißt, ich habe den vorgenerierten Inhalt der statisch rausgeneriert wird und einen dynamischen oder sogar personalisierten Inhalt.

Hier jetzt mal ein Beispiel von News. Das kann aber genauso gut eine Wettervorhersage sein, personalisierte Werbung, was auch immer ich über die Restschnittstelle im CaaS abfragen möchte. So habe ich also auch auf Webseiten die Möglichkeit, vom hybriden CMS zu profitieren. (6 Sek.) Ja, das war so ein bisschen die High Level Architektur. Wie gesagt tiefergehend entweder im Nachgang nochmal mich kontaktieren gerne. Oder wir bei e-Spirit bieten auch Schulungen, Architekturschulungen an, wo das Ganze dann nochmal wirklich in epischer Breite auch nochmal jedem erklärt und nähergebracht wird. Zum Abschluss aber möchte ich nochmal darauf eingehen, was sind denn jetzt wirklich die Dinge, die mich als Entwickler auch voranbringen? Also ich habe vorhin von Enterprise Class Capabilities gesprochen, dass die den Unterschied machen. Und wenn ihr euch erinnert, waren die auf der rechten Seite, das heißt, der im Bereich der Business User. Aber gute Nachricht, auch für Developer ist es so, dass diese Enterprise Class Capabilities den Unterschied machen. Denn bei unserem hybriden CMS ist es also so, dass ich die Architektur mir auswählen kann. Ich habe also eine Wahlfreiheit, welche Architektur ich nehme. Und damit kann ich dann auch die auf mich einströmenden Herausforderungen, die vom Marketing kommen, die von sonstigen Leuten kommen, je nachdem wie es gerade notwendig ist, erfüllen.

Ich kann dazu wählen, ob ich das Cloud oder ein Premise nehme. Ganz wichtiger Punkt, die integrierte CICD und ich bekomme immer drei Instanzen DQP, ja, also Development, Quality und productive. Wir arbeiten mit der Technologie und dem Kubernetes Cluster. Und was auch schon mal angeklungen ist, es ist super einfach mit FirstSpirit Erweiterungen vorzunehmen und andere Systeme zu integrieren und wir legen Wert auf eine entsprechend gute Dokumentation. Sollte heutzutage Standard sein, aber auch nochmal ein separater Hinweis darauf. Und wenn ich das zusammenpacke, durchmische und ein Schild hochhalten würde, käme raus, dass es auch für Entwickler eine neue Art von Agilität und Produktivität ist, die wir damit mit ausliefern. Das ist die zweite Folie, auf die ich nicht weiter eingehen möchte. Das ist was zum Lesen, auch hinterher für zu Hause. Das ist so ein bisschen der, nochmal die Highlights zusammengefasst. Mir ist die nächste Folie nochmal wichtig zum Abschluss, denn das ist ein kleiner Spoiler, auch unseren FirstSpirit Experience Accelerator. Ich habe vorhin erwähnt, es gibt den Ansatz, ich habe ein Headless, CMS und ein Frontend und die einen werkeln in CMS und die anderen machen irgendwas im Frontend. Und da haben wir uns überlegt, das muss doch auch irgendwie bessergehen? Und herausgekommen ist der FSXA, die Abkürzung für FirstSpirit Experience Accelerator, weil das auf Dauer so schwierig auszusprechen ist. Das ist ein, ja, Cloud Offering, wo wir Referenzprojekte mitliefern, ganz wichtig nicht Demo, sondern voll gewartete, vorüberlegte Produkte für eine klassische Website und eine PWA Implementierung inklusive CICD und allem, was man sich so vorstellen kann, kann produktiv eingesetzt werden. Für euch als Entwickler bedeutet das, ich muss nicht bei null anfangen, sondern ich kann, ich habe Referenzen, auf die ich aufbauen kann, die ich wiederverwenden kann und ich kann sozusagen mit Phase zwei starten und die Dinge machen, die wirklich, die mir Spaß machen, die cool sind, die hip sind. Um nicht zu sagen, ich kann mit dem geilen Scheiß anfangen und um das andere hat sich e-Spirit nämlich schon gekümmert. Dazu gibt es aber mehr in einem Webinar, was mein Kollege, der Daniel für euch vorbereiten wird. Das gibt es am 23. April, wo er darauf eingeht, wie ich mit dem FSXA auch wirklich Projekte realisieren kann. Denn der Niklas wird euch jetzt im Anschluss erzählen, wie er das Ganze zu Fuß gemacht hat und trotzdem zum Erfolg gekommen ist. Also an dieser Stelle herzlichen Dank von meiner Seite und ich freue mich über eure Fragen. Entweder jetzt hier live oder gerne auch im Nachgang.

Angela Meyer: Ja, vielen Dank Tim, für deinen Input zu e-Spirit Hybrid CMS. Ich würde hier jetzt direkt weitermachen mit dem Niklas. Ich hoffe du bist bereit, hier jetzt deinen Vortrag zu halten. Ich übertrage mal.

Niklas Krauth: Ja, wenn du meinen Bildschirm überträgst, dann habe ich es gehabt.

Angela Meyer: Schnell den Bildschirm noch, genau.

Umsetzung eines diva-e Kundenprojektes mit dem FirstSpirit Hybrid CMS

Niklas Krauth: Ja genau, einmal noch Vollbild und dann sind wir bereit. Genau, ja, erstmal vielen Dank, danke Tim für die Einführung zum allgemeinen Thema Hybrid FS. Wir haben schon viel über die Vorteile gehört. Ich möchte euch jetzt, Tim hat es schon angedeutet, ein bisschen was darüber erzählen, was es heißt, wenn man das Ganze mal wirklich alles auch umsetzt in einem konkreten Kundenprojekt. Und da, denke ich, wir sind gerade auch jetzt schon mit der Zeit, gehe ich direkt in medias res und wir fangen mal an. Genau, bevor ich euch ein bisschen was darüber erzähle, was wir genau gemacht haben und wie wir das gemacht haben, möchte ich euch erläutern, warum wir uns für hybrides FirstSpirit entschieden haben und warum auch konkretes hybrides FirstSpirit in der Kombination mit Nuxt. Nur am Anfang all unserer Projekte steht immer der Kunde, weil ich denke, diese Zeile aus dem bekannten Song von Freddy Mercury gibt ganz ein bisschen zugespitzt eine durchaus gesunde Kundeneinstellung wieder, ja. Der Kunde möchte einfach, er hat eine hohe Anforderung und unsere Aufgabe und auch unser Anspruch ist es natürlich, diese Dinge möglich zu machen, diese Ansprüche des Kunden auch, diese Erwartungen zu erfüllen. Was hieße das jetzt konkret in unserem Fall, für unser Projekt? Nun zum einen sind dort natürlich die Anforderungen, Tim hat es auch schon gesagt, die man eigentlich immer an die gerade auch große Kunden stets an CMS haben, klassische CMS-Qualitäten. Genau, das Ganze soll sicher sein, das soll auch irgendwie erprobt und verlässlich sein. Zum anderen natürlich auch einen hohen Komfort bieten.

Also gerade das CMA, what you see is what you get, beim Editieren durch die Redakteure ist hier auch einfach eine wichtige Anforderung, dass wir uns nicht durch so eine Formularwüste klicken. Das Ganze soll aber, das war auch hier die konkrete Anforderung, soll wirklich mit einem State of the Art Frontend kombiniert werden. Es soll weg von dem Klassischen, was man kennt, dass einzelne Seiten statisch geladen werden. Sondern das Ganze soll wie aus einem Guss sein. Eine Anwendung, eine interaktive Anwendung, die flüssig animiert, sage ich mal, Übergänge zwischen Seiten erzeugt und einfach eine moderne Visibility auch vermittelt. Mittlerweile immer eigentlich für alle Webprojekte natürlich auch eine Anforderung ist, einfach, dass es in Mobile First umgesetzt wird, also auch eine breite Klasse an Geräten, vom Mobiltelefon über das Tablet bis zum 34-Zoll-Monitor unterstützt. Und schließlich auch immer gerne gesehen ist natürlich ein breiter Browser Support. In unserem Fall dankbarerweise nur bis zum IE 11 herunter, was die Sache noch so halbwegs beherrschbar macht, trotzdem natürlich immer eine Herausforderung. Und sehr interessant das Thema SEO-Optimierung. Die diva-e hat hier ja inhaltlich auch starke Expertise Punkt. Bei der SEO-Optimierung von interaktiven Seiten, die Sie heutzutage ja mit, im Grunde als JavaScript-Anwendung geschrieben werden, ist natürlich immer, dass JavaScript und Suchmaschinen Indizierung immer so ein bisschen ein Konfliktpotenzial haben. Schöner ist dann natürlich, wie man das auch beim klassischen FirstSpirit hat, wenn man statisch vorgerenderte Seiten einfach im Einsatz hat. Genau und schließlich auch immer stets eine Anforderung ist einfach natürlich, das Ganze soll kosteneffizient sein und auch eine gewisse Zukunftsfähigkeit haben. In unserem Fall konkret die Anforderung, dass verschiedene kleinst-, mit demselben Content auch später im Nachgang versorgt werden sollten. Nicht nur die Webseite, sondern es gibt auch ein Intranet und es gibt auch eine Management-App, die zum Beispiel diese Inhalte zum Teil einbinden soll. Kosteneffizient, die alte Webseite hatte eine integrierte Karriereseite, die sollten rausgelöst werden und es sollten zwei eigene Seiten erstellt werden. Hier natürlich mit dem Ziel, maximale Synergien auch zu erzielen. Und schließlich war es so, dass wir auch einfach eine hohe Skalierung im Entwicklungsmodus brauchten, weil es ursprünglich eine relativ enge Deadline gab, die sich dann aus anderen Gründen allerdings nochmal verschoben hat. Warum unter diesem Gesichtspunkt hybrides FirstSpirit? Nun, die klassischen CMS-Qualitäten haben wir da schon gleich out of the Box, da sind wir auf der sicheren Seite. Warum aber Hybrid?

Der zentrale Punkt ist hier die Entkoppelung von Inhalten und Darstellungen. Das ermöglicht es uns, auf der Frontendseite für die Darstellung auf moderne, etablierte Webframeworks zurückzugreifen und die ganzen State of the Art Features zu bekommen. Wir können über das Bildsystem hohe Synergien zwischen den zwei Webseiten erhalten. Wir bekommen durch das hybride CMS die Wiederverwendung des Contents out of the Box und schließlich, ganz wichtig, auch die Skalierbarkeit. Wir brauchen jetzt viel stärkere Frontend Skills. Wir können das Frontend losgelöst vom FirstSpirit Teil in einem RP First Ansatz entwickeln und kriegen dadurch eine ganz andere Skalierbarkeit in unser Projekt hinein. Warum die Kombination Nuxt? Es gibt ja, habe ich eine ganze Reihe Angular React Vue an etablierten Frontend Frameworks. Nuxt selbst basiert im Wesentlichen auf Vue, was meines Erachtens das aktuell beste MBWM-Framework in der Frontendentwicklung ist. Vue-Komponenten könnt ihr optimal losgelöst und parallel entwickeln. Warum nicht Vue direkt? Nuxt bietet hier eine ganze Reihe sehr sinnvoller Konventionen, sinnvoll vor allen Dingen für die Umsetzung solcher klassischen Webseiten, aus meiner Sicht. Für eine App würde ich wahrscheinlich eher auf Vue setzen? Zum anderen und das ist ganz entscheidend, bietet Nuxt uns Server-Side Rending und Pre-Rendering, was es uns ermöglicht, unsere dynamische Single-Page Application SEO optimiert als statischen Inhalt auch für Suchmaschinen, ohne größeren Extraaufwand, bereitzustellen, also wirklich ein enormer Mehrwert. Bevor ich euch zeige, wie wir das alles im Detail umgesetzt haben, möchte ich euch einmal auch meinen Eindruck vermitteln, von dem was wir, was am Ende dabei herausgekommen ist. Ich habe das Ganze hier mal ein Stück weit anonymisiert, da der Kunde auch nicht genannt werden kann. Hier sehen wir mal, hier sind so ein bisschen diva-e Branding, unsere, die erstellte Webseite. Wir sehen, wir haben hier unten ganz klassisch einen Footer, dazwischen haben wir hier den Content-Bereich, bestehend aus verschiedenen Komponenten und hier oben den Header mit einer recht aufwändig gemachten Stage, die die oberste Navigationsebene darstellt. Wenn ich hier draufklicke, dann sehen wir auch, wir haben animierte Seitenübergänge.

Das Ganze ist hochresponsiv direkt im Browser. Ich kann hier oben direkt die Sprache wechseln. Es gibt keinen Page-Reload, das Ganze ist also hochgradig interaktiv. Wenn ich hier auch mal einfach die mobile Ansicht einblende, dann sehen wir auch hier wieder, das Ganze ist Mobile First designt. Wir sehen hier oben, die Leiste klappt dynamisch, geht dynamisch weg oder kommt zurück, je nachdem wie wir scrollen. Wir haben hier klassisches ein klassisches Burger Menü, wo wir auch dynamisch wieder die Sprache wechseln können. Und so haben wir eigentlich wirklich die Anforderung, die wir an das Frontend haben, erstmal auch umgesetzt. Wie sieht das Ganze jetzt für den Redakteur im FirstSpirit aus? Da möchte ich euch, der Einfachheit halber habe ich es ein bisschen vorher aufgezeigt, zeichnet. Ich zeige euch das mal im Video. Wir loggen uns hier ganz klassisch in unser FirstSpirit ein. Was wir hier sehen, ich mache mal kurz Pause, ist, wir haben hier den Anwendungsrahmen, den klassischen FirstSpirit Rahmen. Unsere Anwendung ist in diesen Rahmen via iFrame eingebettet, die Anwendung von innen heraus kommuniziert mit dem Content Creator drum herum. Und wir können, lässt sich hier unser Inhalt wie im klassischen FirstSpirit bearbeiten.

Tauschen wir zum Beispiel hier mal das Bild auf der linken Seite aus und wir sehen, die Anwendung lädt direkt neu und wir haben live das Ganze editiert. Hier kommt uns ein Vorteil auch von Nuxt sehr zugute. Man kann die Anwendung nämlich nicht nur im Server-Side Rendering Modus oder vorgerendert ausspielen, sondern eben auch ganz klassisch als dynamische Single Page Applikation. Und genau diesen Modus setzen wir hier für das Editieren im Content Creator ein. So, wie haben wir das Ganze gemacht? Ich habe ja schon gesagt, der Vorteil vom Hybriden ist auch die Entkoppelung von CMS und Frontend. Und entsprechend haben wir das Ganze API-first entwickelt und wir beginnen hier mit dem API-Design. Kurz zur Erinnerung, wir pflegen die Inhalte im FirstSpirit. First Sprit spielt diese Inhalte dann als JSON auf den CaaS aus und von dort holen wir sie mit unserer Anwendung, ja, über das Rest Interface ab und binden sie in unsere Anwendung ein. Hier auf der linken Seite sehen wir im Grunde den Vorgang beim ersten Seitenaufruf. Unsere Anwendung, der Nutzer besucht die Seite, die Anwendung holt sich vom CaaS zunächst mal einen JSON Fragment, was die routen. Das heißt, die URLs, die unsere Anwendung unterstützt, beschreibt, holt er sich beim CaaS ab. Anschließend holen wir sogenannte globale Inhalte ab. Da geht es um den Teil der Webseite wie Navigation, Header, Footer, die quasi für jede Seite identisch sind.

Und schließlich, anschließend holen wir uns die eigentlichen Inhalte der Seite des JSON, was die eigentlichen Inhalte dieser konkreten Seite beschreibt, ab. Auf der rechten Seite sehen wir dann, wie es aussieht, wenn wir in unserer, auf unserer Webseite zu einer anderen Unterseite navigieren. Die Routen, der globale Inhalt sind stets konstant, sodass wir nur noch die Seitenbeschreibung abrufen müssen. Wie sehen diese einzelnen Teile nun konkret aus? Die Routen sind einfach ein Array, eine Liste von einzelnen Routeneinträgen, bestehend immer aus einem Breadcrumb, dieser Breadcrumb beinhaltet den Namen der Seite und aller Parent-Seiten. Die wirklichen Anzeigenmanen, sodass Sie auf Client-Seite auch für die Anzeige verwendet werden können. Hinzu kommt die Client-URL, die URL, unter der diese Seite wirklich für den Endnutzer auf unserer Website verfügbar sein soll. Wie wir hier schon sehen, wird die im Grunde aus dem Breadcrumbs mehr oder weniger generiert, was sehr schöne, sprechende URLs uns ermöglicht. Und schließlich die Content-URL, das ist die URL, unter der wir den Inhalt dieser Seite bei Bedarf vom CaaS tatsächlich abrufen können. Wie sehen unsere globalen Inhalte aus? Ich habe hier jetzt mal beispielhaft die Navigation dargestellt. Die Navigation ist im Grunde eine verschachtelte Baumstruktur, bestehend aus den einzelnen Einträgen im Navigationsmenü. Jeder Eintrag wird beschrieben durch eine Bezeichnung, durch den Namen, wie er im Menü auch wirklich angezeigt wird und der Client-URL. Die URL für den Content können wir jederzeit aus unserer, ja, in kleinen, vorgehaltenen Routendatei, können wir jederzeit nachschlagen, sodass wir die nicht immer nochmal mitliefern müssen. Als letzter Teil die einzelnen Seiten. Die bestehen aus Metadaten, wie dem Titel der Seite, dem Typ der Seite, wie er im FirstSpirit gepflegt ist, sodass wir da bestimmt auf der Client-Seite unterschiedliche Anzeigen vornehmen können, je nachdem, was es für eine Seite ist. Metadaten wie der Robots, die Information für die Seite, die Übersetzung der Seite und schließlich einer Liste von Komponenten, dazu kommen wir jetzt. Die Komponenten sind die eigentlichen Inhalte der Seite. Das können Dinge sein, wie Überschriften, Text, Bilder, kompliziertere Dinge wie Teaser, Expendables, Tabellen.

Also alles, woraus so eine Seite bestehen kann, was wir im FirstSpirit einem Komponenten zur Verfügung stellen, für den Redakteur. Und jede Komponente ist wiederum beschrieben durch einen Typ, der uns sagt: Okay, was ist das hier für eine Komponente? Welche Frontendkomponente verwenden wir, um diese FirstSpirit Komponente für den Nutzer anzuzeigen? Der Previous ID, die wir brauchen, um dieses Element später im Content Creator zu bearbeiten und dem eigentlichen Content dieser Komponente, der diese Komponente inhaltlich beschreibt. Hier haben wir einen ganz einfachen Fall. Eine Überschrift, da haben wir ein Level, das ist eine Überschrift auf dritter Ebene, das ist der Inhalt der Überschrift und hier gibt es noch optional so eine Unterüberschrift, die man unserer Überschriftenkomponente mitgeben kann. Wie haben wir diese API nun mit FirstSpirit und dem CaaS umgesetzt? Grundsätzlich funktioniert das Ganze so, klassisch definieren wir im FirstSpirit ja unseren HTML-Ausgabekanal, um die eigentliche HTML-Ausgabe herzustellen. In unserem Fall definieren wir einen sogenannten CaaS-Ausgabekanal, der diese Inhalte als JSON ausgibt. Beispiel, ganz klassisch für die Seite, wir legen in unserem FirstSpirit Ausgabekanal ein Objekt an, iterieren über die Inhalte im FirstSpirit, sammeln sie in diesem Objekt und rufen am Ende ein to JSON auf, um diese Inhalte, um dieses Objekt zu serialisieren und auf den CaaS auszuspielen. Ich möchte hier jetzt, aufgrund der Kürze der Zeit, nur auf einen interessanteren Fall eingehen. Nämlich wie stellen wir die Routen her, diese Routendatei, das Route JSON? Das ist nämlich ein bisschen trickreich. Da kann ich auch nur auf den Experience Accelerator hoffen. Wie funktioniert das Ganze? Wir stellen hier ein Mapping her, Content-URL to Route Object. Ein Route-Object ist ein Objekt, was eben genau diese drei Eigenschaften, Content-URL, Client-URL und die Breadcrumb enthält. Wir befüllen dieses Objekt hier durch Aufruf dieses Template. Das Template schauen wir uns gleich noch an. Und sobald wir dieses Objekt haben, machen wir tatsächlich nichts Anderes als ein, unser JSON Mapping herzustellen, wo wir nur eine Property Routes haben. Die entbehrt einfach die Werte dieses Mappings hier sind und rufen unser to JSON auf. Die ganze Magic steckt also hier in unserem Aufruf von to Routes. Wie stellen wir dieses Mapping Content-URL auf Routenobjekte her? Dazu verwenden wir die FirstSpirit CMS Funktion Navigation, die wir im Modus Zeitmap aufrufen.

Was diese Funktion tut, ist, sie läuft über die gesamte Baumstruktur unsere Inhalte im FirstSpirit und ruft für jede Page am Ende diese Funktion, die wir hier definieren, selbst definieren können, auf. Was macht diese Funktion? Diese Funktion erstellt uns zu jeder Seite genau dieses Routenobjekt. Wir speichern sie hier in diese Variable und erstellen das Routenobjekt durch Aufruf der Funktion FT-Route, die den aktuellen Knoten, das heißt, die Referenz auf die aktuelle Seite und die Content-URL bereits übergeben bekommt. Das hier ist jetzt mal diese Funktion FT-Route. Und was die tut ist, sie erstellt ein Objekt, sie kriegt dieses Objekt von außen rein und hängt drei Dinge an, eine Breadcrumb, eine Content-URL- eine Client-URL und die Content-URL. Entscheidend dabei ist die Breadcrumb. Wir haben schon gesehen, die Client-URL, das ist genau das was hier passiert, die entsteht im Endeffekt aus den Breadcrumb-Teilen durch eine gewisse Normalisierung dieser Bestandteile. Die Content-URL haben wir schon in der Hand. Die haben wir gerade von außen eingegeben und machen hier eigentlich nur noch ein URL-Endcoding. Wie stellen wir die Breadcrumb her? Das heißt das Array der Seite und den Namen der Seite und aller ihrer Parent-Seiten, das tun wir erneut durch einen Aufruf hier, der Navigationsfunktion, nur in einem bisschen anderen Modus.

Wir haben hier nicht den Sidepack-Modus, sondern wir rufen da Ganze auf mit Expansion Visibility Purepath, was dafür sorgt, dass wir für den Knoten, der gerade im Kontext liegt, nur noch den direkten Pfad vom Route, vom CMS-Route bis zu dieser Page durchlaufen. Und was wir dann machen ist einfach, für jedes Element in diesem Pfad fügen wir den Breadcrumb hier unten, genau den Displaynamen, den sprachspezifischen Displaynamen dieser Seite hinzu. (Klicken.) (6 Sek.) So viel zum FirstSpirit Teil in aller Kürze.

Frontend: NuxtJS

Kommen wir nun zu unserer Frontendseite, zur Nuxt-SPA. Hier sehen wir mal ein bisschen, ja, eine Übersicht über die Bestandteile, die unsere SPA hat. Da ist zum einen die Routing Middleware, die legt eigentlich fest, was passieren soll, wenn eine bestimmte URL, ein bestimmter Pfad auf unserer Seite aufgerufen wird. Was soll passieren? Was soll geändert werden? Im Normalfall übergibt sie hier an das shared Layout und die generische Seite, die für die eigentliche Darstellung zuständig sind. Hinzu kommt noch unser Store, der den aktuellen Zustand unserer Anwendung hätte. Und ein CaaS-Client Plugin, um die Inhalte dynamisch vom CaaS abzurufen. Das ist eine etwas vereinfachte Darstellung, aber sie zeigt erstmal alle wesentlichen Bestandteile unserer Anwendung. Wenn die Anwendung initialisiert wird passiert Folgendes. Wir rufen die Routen und die globalen Inhalte über das CaaS-Client Plugin ab und speichern sie in unserem Store. Das Routing holt sich die Routen, die wir vom CaaS geladen haben, um später zu entscheiden, was passieren soll, wenn einzelne Client-URLs aufgerufen wird.

Das shared Layout bindet sich an die globalen Inhalte, um Header, Footer und den Anwendungsrahmen bereitzustellen. Wenn nun eine konkrete URL aufgerufen wird, kommen wir hier oben in die Routing Middleware hinein. Der Router guckt, okay, liegt irgendein allgemeiner Fehler vor? Das kann zum Beispiel der Fall sein, wenn entweder unsere Routen oder globalen Inhalte gar nicht geladen werden konnten und wir eigentlich nichts Sinnvolles machen können, dann zeigen wir eine generische Fehlerseite an. Im anderen Fall überprüfen wir anhand der Routen aus dem Store, handelt es sich um eine unterstützte, bekannte Route mit sinnvollem Content? In dem Fall rendern wir diese Seite, indem wir hier die generische Seite, zu der ich gleich noch kommen werde, zur Anzeige bringen. Ist das eine uns unbekannte Route, zeigen wir eine 404-Seite an.

Das Rendering der eigenen Seite ist natürlich der Normalfall, wenn eine gültige URL aufgerufen wird. Wir ändern zunächst das geteilte Layout, was alle Seiten gemeinsam haben, mit Hilfe der global beschriebenen Inhalte. Und in dieses globale Layout werden wir dann den eigentlichen, die eigentliche Seite, die ihrerseits wiederum aus den ganzen Komponenten eigentlich nur eine Abfolge von Komponenten ist und beim Aufruf der Seite vom CaaS geladen werden, zur Laufzeit. Der Trick sind im Grunde diese dynamischen Komponenten. Das ist etwas, wo uns tatsächlich Vue sehr zu Pass kommt. Alle unsere Seiten sind im Grunde gleich aufgebaut. Sie sind eine Liste von Komponenten und wir kommen mit sehr wenig Code, im Endeffekt mit sehr generischem Code aus, den wir hier sehen. Das hier ist tatsächlich, es gibt, der Kern der gesamten Anzeigelogik unserer Anwendung. Was wir tun ist, wir iterieren hier über die Komponenten der Seite. Und für jede Komponente binden wir auf Client-Seite dynamisch eine Vue-Komponente, das geht hier mit diesem Tec-Component.

Und hier über IS sagen wir, was für eine Vue-Komponente soll es denn jetzt sein, einen Header, ein Textblock, ein Bild, was auch immer? Hier wird im Grunde der FirstSpirit Type mit dieser Funktion auf unseren Vue-Komponententyp gemappt. Und auf diese Art und Weise wird dynamisch jede Komponente, die wir unterstützen, im Client instanziiert. Das hier reicht im Grunde, um alle Seiten darzustellen. Soviel zur Darstellung der Seiten. Wir müssen natürlich unsere Anwendung aber auch noch in den Content Creator integrieren. Wir haben schon vorhin gesehen, die Anwendung wird in einem iFrame in den Content Creater Rahmen eingebettet. Um nun die Kommunikation zwischen unserer Anwendung und dem Content Creator, die an bestimmten Punkten einfach notwendig ist, zu ermöglichen, wird in unsere Anwendung das von FirstSpirit bereitgestellte SnapJS eingebunden. Das exposed innerhalb unserer Anwendung ein Objekt TPP Snap, was es uns erlaubt, mit dem Content Creator zu interagieren. Hier ist, sage ich mal, das Grundgerüst dessen, was wir brauchen, um erfolgreich unsere Anwendung in den Content Creator zu integrieren, mal dargestellt. Was wir tun ist einfach, beim im Grunde Initial, beim Laden der Anwendung sagen wir, registrieren wir einen Callback für das InitEvent des Content Creators und sagen. Wenn der Content Creator erfolgreich geladen ist, dann registrieren wir bestimmte Event Handler, die ich jetzt hier nicht im Einzelnen zeige.

Da geht es um Themen, wir können uns auf Events registrieren wie, eine neue Seite wurde erstellt, ein Inhalt wurde geändert, die Navigation wurde geändert und können dann in unserer Anwendung entsprechend darauf reagieren und wir können bestimmte Konfigurationen am Content Creator vornehmen. Was wir auch tun, zum Beispiel zusätzliche Buttons für bestimmte Elemente anlegen. Darüber hinaus die Editier-Funktion, die wir vorhin gesehen haben, dass wir die Boxen, um die Elemente zum Bearbeiten bekommen, erhalten wir schlichtweg, indem wir an die zu bearbeitenden Elemente einen Attribut Data Preview ID im HTML anheften und out of the Box bekommen wir diese Editiermöglichkeiten. Build und Enviroments, wir haben hier ein Web-Pack-Build im Einsatz. Das bringt uns diverse Vorteile, Minification, Tree Shaking, Transbelation Hinting, einfach viele der Dinge, die wir brauchen, um eine performante und moderne Anwendung zur Verfügung zu stellen. Wir sehen hier oben beispielhaft ein Environment. Was wir machen ist, wir definieren für unsere verschiedenen Stages, Depth, Test, Production verschiedene, können wir verschiedene Environments konfigurieren und über den Webpack Build in die Anwendung injecten. Und auf diesem Weg können wir sehr dynamisch eigentlich diese Anwendung konfigurieren, für die verschiedenen Umgebungen. Und gleichzeitig ermöglicht uns der Wepack Build auch im Grunde dynamisch, je nach Umgebung, verschiedene Assets in unsere Anwendung einzubinden. Zum Beispiel verschiedenes Styling, verschiedene Fonts, verschiedene Komponenten.

Und das nutzen wir, um aus derselben Code-Basis, mit minimalen Anpassungen, zwei verschiedene Anwendungen, zum einen für die Webseite, zum anderen für das Karriereportal zu bauen. Das heißt, wir haben hier über unserem Webpack Build, über unser moderne Tooling maximale Synergien, was die Wiederverwendung unseres Codes für die zwei Webseiten, die wir unterstützen, angeht. Als Letztes da sehen wir Deployment and Prerendering. Wir versionieren unsere Inhalte sowohl Frontend, wie auch FirstSpirit mit Git und deployen das Ganze GitLab CI automatisch auf unsere Stages. Das Prerendering ist natürlich ein bisschen ein spezielles Thema. Was wir tun müssen, ist, wenn sich Inhalte im FirstSpirit verändern, müssen wir unsere Seiten noch einmal komplett statisch herausrendern und auf dem Web-Server ablegen. Das Ganze funktioniert so, dass der FirstSpirit Server unseren kleinen Prerendering-Service, der die Seiten dann noch einmal vollständig neu baut, anstößt, sobald sich bei ihm Inhalte ändern und wir diese Inhalte dann als statisches HTML auf dem Live-Webserver ablegen. So, zum Abschluss natürlich die alles entscheidende Frage. Hat sich das Ganze denn gelohnt, der ganze Aufwand? Schauen wir uns mal an, wie sich das Ganze auf der Content-Seite darstellt.

Hier oben sehen wir mal, der Content, der bei einem initialen Aufruf unserer Seite geladen wird. Was wir schon sehen, auch schon beim ersten Aufruf fällt der größte Teil des Contents tatsächlich auf Bilder. Das heißt, auf die eigentlichen Inhalte der Seite, auf die wir in dem Sinne keinen Einfluss haben. Wenn wir mal hier unten gucken, JavaScript, SCC uns Fonts zusammengenommen sind ungefähr 300 Kilobyte, was wirklich sehr kompakt ist. Und was wir auch sehen, durch Einsatz von Cashing und Cash Facing bekommen wir es tatsächlich hin, dass schon beim zweiten Aufruf der Seite und natürlich sowieso, solange nur auf kleinen Seiten navigiert wird, wir außer den wirklichen Inhalten, dem HTML und den Bildern, gar nichts nachladen müssen. Wir haben also tatsächlich 300 KB initiale Load und danach überhaupt kein Overhead mehr für unsere Anwendung. Das Ganze wird uns entsprechend auch tatsächlich gelohnt. Wir sehen hier mal die, also schon regelrecht unheimlichen Page Speed Scores, die uns Page Speed Insides ausspuckt. Einmal links für die mobile Seite und rechts für die eigentliche Webseite.

Und ich denke, es zeigt auch, dass wir hier wirklich eine sehr performante und hoch optimierte Lösung bereitgestellt haben. Gehen wir nochmal durch und schaue uns an, was wir jetzt eigentlich in Summe haben. Jawohl, sicher und etabliert ist es allemal. Wir haben das gute FirstSpirit im Einsatz, Visevic Editing haben wir vorher im Video gesehen, funktioniert ganz wunderbar. Wir haben eine interaktive Anwendung mit Animation und allem ohne Pay Preload vom Server. Wir haben Mobile First Design auch vorhin live gesehen. Den guten Browser Support haben wir durch unseren Webpack Build, der uns Polyfills, Transpilation und so weiter liefert. Wir haben CEO optimierte Seiten durch unser statisches Prerendering, was bedeutet, dass wir tatsächlich vorgerenderte Seiten an Google ausliefern, die komplett ohne JavaScript erstmal so aussehen, wie sie aussehen sollen. Und wir haben den Reuse of Content für andere Clients durch den Einsatz des hybriden FirstSpirit über die CaaS. Synergien zwischen Corporate-Seite und Webseite, auch wieder durch unseren Build für verschiedene Umgebungen. Und es ist uns gelungen, durch die Entkoppelung von Frontend und FirstSpirit Entwicklungen und die Entkoppelung der Komponentenentwicklung eine hohe Velocity in unsere Entwicklung zu bringen. Sodass wir in Summe in jedem Fall sagen können, der Einsatz von hybridem FirstSpirit hat sich für unser Projekt definitiv gelohnt. Ja so, eine Minute habe ich überzogen, aber ich habe mich eigentlich trotzdem schon mehr beeilt, als ich eigentlich wollte. (Lachen.)

Q&A

Angela Meyer: Ja, vielen Dank Niklas, (Niklas Krauth: Bitte schön.) dir auch mit deinem Input zu der Kundenlösung. So, jetzt können gerne noch Fragen gestellt werden, die hier jetzt offen sind. Und ich schaue hier gerade mal noch in den Chat rein. Ansonsten ist natürlich auch schon die Zeit vorangeschritten und Fragen können gerne im Nachgang gestellt werden, auch an webinar@diva-e.com. So, ich scrolle mal hier kurz durch und nehme mir mal eine Frage hier mit auf. Und zwar,

Gibt es von e-Spirit oder diva-e Unterstützung bei einer hybriden Architektur und der Integration von mehreren Touchpoints beziehungsweise Clients? Und welche Clients sind zum Beispiel in dem vorgestellten Projekt integriert?

Niklas Krauth: (6 Sek.) In unserem Projekt ist es erstmal so, dass wir selbst nur für die Anbindung der Webseite als, sage ich mal, primären Client zuständig gewesen sind und auch nur diesen Teil umsetzen. Grundsätzlich sind wir natürlich immer gerne auch bereit und in der Lage, andere Clients anzubinden. Aber in diesem konkreten Projekt haben wir tatsächlich nur die Webseite als, sage ich mal, First-Class Citizen und primären Client angebunden, ja. Und auch e-Spirit Seite ist es so, dass wir explizit einen Professional Service haben, der jederzeit auch den Kunden zur Verfügung steht und eben genau dabei hilft, Projekte von der initialen Phase bis zur Umsetzung sicher mitzubegleiten.

Angela Meyer: Okay, sehr gut. Also genau, gerne hier bei konkreten Anliegen einfach auf unsere Experten zukommen. Wir können da Hilfestellung geben. So, ja dann würde ich noch gerne unsere nächsten Webinare bewerben, die wir mit unseren Kunden und Partnern veranstalten, in den nächsten Wochen. Einfach auf unserer Webseite vorbeischauen und dort findet ihr unsere diva-e Webinare, Webinarreihe und wir freuen da uns auf Ihre Teilnahme. Dann danke Niklas und danke Tim für euren interessanten Input heute zu FirstSpirit Hybrid CMS. Und ja, vielen Dank und ich würde sagen, bis zum nächsten Mal.

Niklas Krauth: Ja, vielen Dank und allen eine gute Zeit.

Angela Meyer: Danke, euch auch.

Niklas Krauth: Danke.

Tim Rother: Danke. Ciao.