Headless Systeme wie Storyblok sind schon seit einer Weile in aller Munde. Doch nicht immer lohnt es sich sie einzusetzen. Allgemein betrachtet hat jedes System seine Vor- und Nachteile und da bilden headless Systeme wie Storyblok keine Ausnahme. Im Folgenden kann ich nur für Storyblok sprechen, aber es mag auch für andere headless CMS Systeme gelten.

Zuerst kurz eine kleine Definition bzw. Beschreibung: Bei einer Website, die mit Storyblok betrieben wird, ist der Inhalt mit seinen Daten und seinen Strukturen entkoppelt von der Präsentationsschicht, dem Frontend. Das Frontend holt sich dann seine Daten via API.

Wo Storyblok allein nicht helfen kann

Storyblok ist für das Hosting der CMS-Daten zuständig ist, und zwar ausschließlich dafür. Das heißt auch, dass der Aufwand für die Implementierung anderer Dienste schon ein Hindernis bzw. Mehraufwand darstellt.

Ein Beispiel:
Fast jede Website hat mittlerweile ein Kontaktformular oder man kann sich auf der Website für einen Newsletter anmelden. Dies hat aber nichts mit Storyblok zu tun und muss als separate Implementierung betrachtet werden. Damit steigt auch der Entwicklungsaufwand für die komplette Website.

Das verwenden von Stoyblok in einem Team von Entwicklern hat seine Tücken. Es erfordert Erfahrung im Team am gleichen Storyblok Projekt zu arbeiten.

Wo Storyblok punktet

Entwickler schätzen Storyblok, weil die Technologie, die man für das Frontend verwendet frei wählbar ist. Da Storyblok seine Daten via CDN also via Content Delivery Network zur Verfügung stellt, werden die Daten sehr schnell geladen, egal von wo aus man die Website aufruft. Content Editoren schätzen den Visual Editor von Storyblok, weil das Aufbereiten von Inhalten damit sehr komfortabel ist.

Fazit

Wenn eine Website eine gewisse Größe hat, oft geändert wird und evtl. auch mehrere Content Editoren gleichzeitig pflegen, dann kann Storyblok sich von seiner besten Seite zeigen.

Umgekehrt, wenn eine Website überschaubar groß ist und nicht oft geändert wird, sondern eher als eine Visitenkarte im Internet dient, dann sollte man vielleicht Storyblok nicht verwenden.

Headless systems such as Storyblok have been on everyone's lips for a while now. But it's not always worth using them. Generally speaking, every system has its pros and cons, and headless systems like Storyblok are no exception. In the following I can only speak for Storyblok, but it may also apply to other headless systems.

Firstly, a brief definition or description: In a website that is operated with Storyblok, the content with its data and structures is decoupled from the presentation layer, the frontend. The frontend then retrieves its data via API.

Where Storyblok alone cannot help

Storyblok is responsible for hosting the CMS data, and only for that. This also means that the effort required to implement other services is already an obstacle or additional expense.

An example: Almost every website now has a contact form or you can sign up for a newsletter on the website. However, this has nothing to do with Storyblok and must be considered a separate implementation. This also increases the development effort for the entire website.

Using Stoyblok in a team of developers has its pitfalls. It requires experience to work in a team on the same Storyblok project.

Where Storyblok scores

Developers appreciate Storyblok because the technology used for the front end is freely selectable. As Storyblok makes its data available via CDN (content delivery network), the data is loaded very quickly, regardless of where the website is accessed from. Content editors appreciate Storyblok's visual editor because it makes editing content very convenient.

Conclusion

If a website is of a certain size, is changed frequently and is possibly maintained by several content editors at the same time, then Storyblok can show its best side.

Conversely, if a website is of a manageable size and is not changed often, but rather serves as a business card on the Internet, then Storyblok should perhaps not be used.