Meine Headless-Leistungen Headless CMS | Content Management neu gedacht
Ein Headless CMS ist ein reines Backend-Content-Management-System, das von Grund auf als Content-Repository aufgebaut ist und den Zugriff auf Inhalte über eine RESTful-API ermöglicht.
Welche Vorteile bietet eine Headless-CMS-Architektur?
Ein Headless CMS besticht in der Praxis vor allem durch die hohe Flexibilität und die vielen Einsatzmöglichkeiten, welche mit den klassischen Content-Management-Systemen nur schwer abgedeckt werden können.
Die Vorteile einer Headless-Architektur für Marketingverantwortliche
- Inhalte müssen nur einmal im System eingepflegt werden und können dann in einem standardisierten Format (JSON/XML) für unterschiedliche Kanäle ausgespielt werden
- Inhalte können flexibler strukturiert und durch Zusatzmodule angereichert werden
- Sie müssen weniger Zeit für die Administration aufwenden
Die Vorteile einer Headless-Architektur für Entwickler
- Freie Wahl der Frontendarchitektur / neues Frontend lässt sich parallel implementieren
- Backend und Frontend können unabhängig voneinander individuell weiterentwickelt werden
- Neue Bereiche können kontinuierlich ausgerollt und für bestimmte Kanäle exklusiv bereitgestellt werden
Flexibles Content Management ohne Beschränkungen
Das Headless CMS bildet die Basis einer modernen Website oder App-Architektur und wird dabei allen neuen Anforderungen an ein flexibles und skallierbares System gerecht.
Benötigen Sie Unterstützung bei ihrem nächsten Webprojekt?
Niels Langlotz
Web-Entwickler
Tel: +49 176 45 606 488
E-Mail: info(at)typoniels.de
Meine Erfahrung als Entwickler setze ich für Sie gerne bei ihrem nächsten Projekt mit ein, sprechen Sie mich einfach an.
Häufige Fragen & Antworten
Die Antwort auf folgende Fragen könnte Sie auch interessieren
Front- und Backend einer Webanwendung zu trennen und als eigenständige Systeme zu betrachten, hat in der Praxis einige Vorteile, unter anderem ist so eine flexible und weitestgehend unabhängige Weiterentwicklung sowie die Nutzung unterschiedlicher technologischer Unterbauten für Frontend und Backend möglich.
1. Frontend und Backend kennen sich nicht
Hier kann es schnell zu Struktur-Problemen innerhalb der Anwendung kommen, was sich besonder gut mit folgenden Beispielen verdeutlichen lässt. In Szenario 1 möchte ein Redakteur im Texteditor einen weiteren Artikel verlinken, dessen absoluter Link aber noch gar nicht feststeht und durch die flexible Frontend-Architektur erst beim Generieren der Anwendung erstellt wird. Für den Redakteur ist hier nahezu unmöglich, verlässliche Links anzulegen. Im Szenario 2 soll in der Anwendung eine dedizierte Such-Funktion zum Einsatz kommen, dessen Datenbasis aus dem Backend gespeist wird, was insbesondere durch die entkoppelte Darstellung im Frontend schnell zu Inkonsistenzen und Abnahme der Nutzbarkeit der Suchfunktion führen kann.
2. Die Redaktion hat keine Live-Vorschau
Zugegeben, mit einem recht hohem Aufwand lässt sich diese Einschränkung mit einer eigenständigen Anwendung (Shaddow-Frontend) beheben, die dem Redakteur die komfortable Arbeit in einem simulierten Frontend ermöglicht, in der Regel arbeitet der Redakteur aber in einem minimalistisch eingerichteten Editor, ohne den Lesefluss in der realen Anwendung testen und kontrollieren zu können, bei klassischen Systemen, die Frontend und Backend nicht trennen, ist hier eine einfache Kontrolle möglich.
3. Es müssen mehrere Systeme gewartet werden
Mit jedem weiteren System wächst auch die Infrastruktur und der operatieve Aufwand zur Wartung und Pflege. Dies benötigt dann in der Regel auch weitere Mitarbeiter.
Unerwähnt sollte aber nicht bleiben, dass eine reine Frontend-Anwendung in der Regel eine höhere Sicherheit genießt und weniger Ressourcen im Betrieb benötigt.
