DEFREN

Login und Suche



CH Open Sponsoren

AdNovum Informatik AG - /ch/open-Sponsor

Ist “Head­less CMS” die Zukunft oder nur ein wei­te­res Buzzword?

von Mar­tin Wie­der­kehr | 01.02.2017

In der letz­ten Zeit hört man immer wie­der von Head­less oder Deco­u­pled CMS, doch was ist damit über­haupt gemeint?

Tra­di­tio­nel­ler­weise funk­tio­nie­ren die meis­ten Con­tent Manage­ment Sys­teme (TYPO3, Dru­pal und wie sie alle heis­sen) so, dass das­selbe Sys­tem sowohl für die Redak­ti­ons– und Admi­nis­tra­ti­ons­ober­flä­che zustän­dig ist wie auch gleich­zei­tig die Front­en­d­aus­gabe übernimmt.

Bei einem Deco­u­pled CMS wer­den diese Auf­ga­ben nun auf unter­schied­li­che Sys­teme auf­ge­teilt. Das eigent­li­che CMS wird kopf­los, was nichts ande­res heisst, als dass die Inhalts­ver­wal­tung wei­ter­hin über das CMS abge­deckt wird. Die Aus­gabe der Daten erfolgt aber über eine andere Appli­ka­tion, bei­spiels­weise über einer auf Java­Script basier­ten Frontend-​App. Die ver­wen­dete Tech­no­lo­gie spielt dabei eine weni­ger wich­tige Rolle. Die zur Ver­fü­gung gestell­ten Daten kön­nen in völ­lig unter­schied­li­chem Kon­text ver­wen­det wer­den und das ist genau der Clou an der Sache.

Die Vor­teile eines Deco­u­pled CMS

Aus der ver­wen­de­ten Archi­tek­tur erge­ben sich diverse Vor­teile für den Kun­den sowie für den Hersteller:

  • Weg­fall einer mono­li­thi­schen Archi­tek­tur: Ein­zel­kom­po­nen­ten kön­nen über die Zeit ein­fach aus­ge­tauscht wer­den. Dies ermög­licht über die Lauf­zeit eine Kos­ten­er­spar­nis und erhöht mass­geb­lich die Zukunfts­si­cher­heit der Lösung.
  • Hohe Ska­lier­bar­keit und (Geo-)Redundanz
  • Durch die sau­bere Auf­tei­lung der Kom­po­nen­ten ist es im kon­kre­ten Fall mög­lich, die API Kon­nek­to­ren wie­derum auf meh­rere Sys­teme zu ver­tei­len. Dies ermög­licht es bei­spiels­weise, pro Schnitt­stelle eine eigene Konnektor-​Instanz lau­fen zu las­sen um Quer­ef­fekte bei Last­spit­zen ein­zel­ner API Abfra­gen zu umgehen.
  • Die Tren­nung von Backend und Front­end ermög­licht eine effi­zi­ente Zusam­men­ar­beit mit Drit­ten (zum Bei­spiel einer auf Frontend-​Apps spe­zia­li­sier­ten Agen­tur) und den Ein­satz von deren bevor­zug­ter Technologie.
  • Die freie Wahl ein­zel­ner Kom­po­nen­ten ermög­licht einen opti­ma­len Tech­no­lo­gie­stack für ein­zelne Teil­auf­ga­ben, bei­spiels­weise Authentifizierungsservices.

Für wen eig­net sich diese Architektur?

Trotz der offen­sicht­li­chen Vor­teile eig­net sich eine auf dem Headless-​Prinzip basier­ten Archi­tek­tur nicht für jeden Kun­den. Auf die Nach­teile gehen wir gleich noch detail­lier­ter ein. Grund­sätz­lich sehen wir aktu­ell, dass das Prin­zip in fol­gen­den drei Ein­satz­sze­na­rien seine Stär­ken aus­spie­len kann:

  • Umfang­rei­cher Ein­satz von meh­re­ren Daten­quel­len und Fremdsystemen
  • Hohe Anfor­de­run­gen an die Skalierbarkeit
  • Zusam­men­ar­beit mit einer exter­nen Front­end Agentur

Die Nach­teile

Es erge­ben sich durch die Archi­tek­tur aber auch gewisse Nach­teile, über wel­che man sich im Vorn­her­ein im Kla­ren sein sollte. Es han­delt sich hier­bei nicht nur um tech­ni­sche Hin­der­nisse. Teil­weise feh­len auch ein­fach Basis­funk­tio­na­li­tä­ten, wel­che wir von beste­hen­den Lösun­gen gewohnt sind.

  • Die Out-​of-​the-​Box Funk­tio­na­li­tät eines CMS kann viel­fach nicht 1:1 ver­wen­det wer­den. Dies bedeu­tet: einen erhöh­ten Initi­al­auf­wand, auch für ver­meint­lich ein­fa­che Funktionen.
  • Durch die Ver­tei­lung der Archi­tek­tur auf diverse Ein­zel­kom­po­nen­ten ist die Ein­stiegs­hürde beim Hosting/​Betrieb gegen­über einer klas­si­schen Archi­tek­tur höher. Dies schlägt sich auch in den ent­spre­chen­den Kos­ten nieder.
  • Die Anfor­de­run­gen an Pro­jekt­mit­ar­bei­ter fal­len gege­be­nen­falls höher aus, da meh­rere unter­schied­li­che Tech­no­lo­gien im Ein­satz sind.

Mit der Zeit wie­gen gewisse Nach­teile — wie bei­spiels­weise das Feh­len von Out-​of-​the-​Box Funk­tio­na­li­tät — sicher­lich weni­ger stark, da man auf ein Set von bereits umge­setz­ten Funk­tio­na­li­tä­ten zurück­grei­fen kann.

Deco­u­pled CMS @snowflake

Anhand eines aktu­ell in der Umset­zung befind­li­chen Pro­jek­tes, möch­ten wir einen mög­li­chen Tech­no­lo­gie­stack vor­stel­len. Im kon­kre­ten Fall haben vor allem die hohe Anzahl an aktu­ell und poten­ti­ell ange­bun­den APIs sowie die Zusam­men­ar­beit mit einer spe­zia­li­sier­ten Front­end Agen­tur auf unsere Ent­schei­dung eingezahlt.

TYPO3 Backend

Als CMS kommt hier­bei TYPO3 zum Ein­satz. Nun ist TYPO3 viel­leicht kein klas­si­sches Deco­u­pled CMS, aber nie­mand hat behaup­tet, dass man die ent­spre­chen­den Anpas­sun­gen nicht vor­neh­men kann. Die Wahl von TYPO3 zeigt sogar bei­spiel­haft die Ele­ganz die­ser Archi­tek­tur: Der Kunde hatte näm­lich bereits frü­her TYPO3 im Ein­satz und kann durch die wei­tere Ver­wen­dung von TYPO3 bei der Schu­lung von hun­der­ten Redak­teu­ren mas­siv Kos­ten ein­spa­ren und auf eine grös­sere Akzep­tanz zählen.

In die­sem Case dient TYPO3 der Erfas­sung von sta­ti­schen Inhal­ten sowie der Kon­fi­gu­ra­tion der Aus­gabe von Daten aus Dritt­sys­te­men. Bei­spiels­weise kann inner­halb von TYPO3 eine Pro­jekt­an­sicht für das Front­end kon­fi­gu­riert wer­den, wel­che nur Pro­jekte einer bestimm­ten Kate­go­rie aus­gibt. Die effek­ti­ven Daten der Pro­jekte und deren Kate­go­rie­zu­wei­sung kommt dabei via Web­schnitt­stelle aus einer exter­nen Projektdatenbank.

Tech­nisch gese­hen ist für uns TYPO3 neben den rest­li­chen “klas­si­schen” Schnitt­stel­len eben­falls ein sol­cher Daten­lie­fe­rant. Sämt­li­che Schnitt­stel­len­da­ten wer­den mit­tels Sym­f­ony basie­rend auf API Kon­nek­to­ren in eine zen­trale Elas­tic­se­arch zur Daten­hal­tung eingespielt.

Obwohl Elas­tic­se­arch eben­falls eine rudi­men­täre Mög­lich­keit zur Asset­ver­wal­tung bie­ten würde, haben wir auf einen eige­nen Sto­ra­ge­ser­ver gesetzt. Die­ser über­nimmt zusäz­lich das Ska­lie­ren auf unter­schied­li­che Bild­grös­sen für eine responsive Bild­dar­stel­lung sowie andere für das Front­end wich­tige Bild­be­ar­bei­tun­gen. Als Tech­no­lo­gie kommt hier­bei Node.js und Nginx zum Ein­satz, wel­che das ein­fa­che Par­al­le­li­sie­ren und Pipen der Berech­nun­gen ermöglicht.

Search­dri­ven Frontend

Sämt­li­che Daten ste­hen nun also in der Elas­tic­se­arch in einer “nor­ma­li­sier­ten” Form zur Ver­fü­gung und kön­nen daher dank einer durch­dach­ten Daten­ar­chi­tek­tur ein­fach nach unter­schied­lichs­ten Kri­te­rien durch­sucht und facet­tiert wer­den. So kann man ein­fach dar­ge­stellt sagen: Das Front­end — basie­rend auf Node.js, Knockback.js und Hand­le­bars — setzt bei jedem Auf­ruf eine Suche ab und stellt sie in einer vor­de­fi­nier­ten Form dar.

Und hier schliesst sich der Kreis zum TYPO3 Backend und der Schnittstellen-​Konfiguration: Die Kon­fi­gu­ra­tion für die Aus­gabe von API Daten wird als Such­ab­frage an das Front­end gelie­fert, wel­ches dann eine ent­spre­chende Abfrage an die Elas­tic­se­arch absetzt. Die klas­si­sche Suche über das Such­feld der Seite ist also tech­nisch gese­hen genau dasselbe.

Hier­durch erge­ben sich einige span­nende Use Cases und Spie­le­reien: Stel­len Sie sich vor, Sie befin­den sich auf einer klas­sisch anmu­ten­den Web­site und fan­gen an, im Such­feld nach einem Begriff zu suchen. In Echt­zeit wer­den nun die Inhalte auf der Web­site neu arran­giert oder nach­ge­la­den, aus­ge­blen­det oder hervorgehoben.

Per­for­mance und Sicherheit

Zuge­ge­be­ner­mas­sen stellt diese Archi­tek­tur auch erhöhte Anfor­de­run­gen an die Per­for­mance und Sicher­heit. Aus die­sem Grund setz­ten wir auf einen auf Var­nish und Nginx mit Naxsi und SPDY basie­ren­den Reverse-​Proxy.

Die­ser über­nimmt einer­seits die Funk­tion einer Fire­wall, indem er sämt­li­che ein­ge­setz­ten Kom­po­nen­ten vom Inter­net abtrennt und Zugriffe IP-​basiert nur auf die benö­ti­gen Res­sour­cen ermög­licht. Ande­rer­seits set­zen wir ihn auch für In-​Memory Caching ein, um häu­fige Abfra­gen gar nicht erst an die rechen­in­ten­si­ve­ren Kom­po­nen­ten wei­ter­rei­chen zu müssen.

Genau das brau­chen wir!

Nichts ande­res woll­ten wir mit die­sem Blog­post errei­chen. Das tönt nicht nur hoch­in­ter­es­sant, genau das ist es auch!

Las­sen Sie sich von uns zum Thema Deco­u­pled CMS bera­ten. Wir zei­gen wir Ihnen gerne in einem per­sön­li­chen Gespräch die Mög­lich­kei­ten und Chan­cen die­ser Archi­tek­tur für Ihren Use Case auf.



Weiterführende Informationen aus dem OSS Directory

snowflake productions gmbh

snowflake.ch | 50 Mitarbeitende | 36 Referenzen | 40 Produkte


We Do. Digital Business.
snowflake bietet umfangreiche Dienstleistungen für das Digitale Business. Die angebotenen Dienstleistungen sind gänzlich auf unsere Kunden und den Markt abgest...

» Mehr
Letzte Aktualisierung: 21.02.2017  -  Anzahl Ansichten seit dem 01. April 2013: 1213
Erstellt: 14.10.2012

TYPO3

Anwendungen / Enterprise Content Management (Document and Content Management)
22 Firmen, 66 Referenzen


TYPO3 ist ein Enterprise-Content-Management-Framework auf Open Source Basisum Internet- und Intranet-Sites aufzubauen und zu betreiben. Das lizenzkostenfreie System ist bei KMU, Konzernen und ...

» Mehr
Letzte Aktualisierung: 13.12.2016  -  Anzahl Ansichten seit dem 01. April 2013: 123
Erstellt: 14.09.2012

Elasticsearch

Infrastruktur / Suchmaschinen
10 Firmen, 5 Referenzen


Elasticsearch ist eine Suchmaschine auf Basis von Lucene. Das in Java geschriebene Programm speichert die Suchergebnisse in einem NoSQL-Format (JSON) und gibt sie über ein RESTful-Webinterfac...

» Mehr
Letzte Aktualisierung: 24.11.2016  -  Anzahl Ansichten seit dem 01. April 2013: 146
Erstellt: 10.01.2014

Elastic Search mit TYPO3 für Zürcher Hochschule der Künste

Branche: Bildung Forschung
Ausgeführt durch snowflake productions gmbh


Die neue Website setzte snowflake mit einer nicht alltägliche Lösung mittels Headless CMS um. Martin Wiederkehr, Business Manager bei snowflake erklärt den Zusammenhang so: „In dem Proje...

» Mehr
Letzte Aktualisierung: 31.01.2017  -  Anzahl Ansichten seit dem 01. April 2013: 245
Erstellt: 30.01.2017

Mitgliedschaft bei /ch/open

Der Vorstand der /ch/open wird jährlich an der Mitgliederversammlung gewählt und arbeitet vorwiegend ehrenamtlich. Werden Sie Mitglied des Vereins /ch/open und unterstützen Sie die Förderung von Open Source Software in der Schweiz.

Einzelmitgliedschaft
Für alle, die persönlich die Anliegen und Aktivitäten von /ch/open unterstützen und kostenlos an Abendveranstaltungen und am Open Business Lunch teilnehmen möchten.
CHF 100.– pro Jahr

Einzelmitgliedschaft für Personen in Ausbildung
Personen in Ausbildung erhalten eine Ermässigung des Mitgliederbeitrags.
CHF 20.– pro Jahr

Kollektivmitgliedschaft
Für Unternehmen, öffentliche Verwaltung, Schulen und andere juristische Personen: Alle Mitarbeiter solcher Organisationen geniessen die gleichen Möglichkeiten und Vergünstigungen wie Einzelmitglieder. Eine definierte Kontaktperson erhält alle Korrespondenz.
CHF 450.– pro Jahr

Sponsormitgliedschaft
Für Mitglieder, welche die Anliegen der /ch/open besonders unterstützen möchten: Sponsormitglieder können Anfang Jahr am /ch/open Sponsoren-Dinner teilnehmen, werden auf der /ch/open Website und dem Portal www.opensource.ch mit Logo aufgeführt, in allen Mailings namentlich mit Link erwähnt und können beliebig viele Projekte und Referenzen im OSS Directory verlinken.
CHF 1000.– pro Jahr

Die Anmeldung für die Mitgliedschaft, die Vereinsstatuten sowie viele weitere Informationen sind auf der Website zu finden:
http://www.ch-open.ch/anmeldeformular_mitgliedschaft/

Twitter Feed







Links

Über unsNewsletterKontaktNutzungsbedingungenCH Open Initiativen