Headless architecture

My headless services in detail Headless CMS | Content Management rethought


A headless CMS is a pure backend content management system that is built from the ground up as a content repository and allows access to content via a RESTful API.


What advantages does a headless CMS architecture offer?

A headless CMS impresses in practice above all by its high flexibility and the many possible applications, which can hardly be covered by the classic content management systems.

The advantages of a headless architecture for marketing managers

  • Content only needs to be entered once in the system and can then be played out in a standardized format (JSON/XML) for different channels
  • Content can be structured more flexibly and enriched with additional modules
  • You need to spend less time on administration

The advantages of a headless architecture for developers

  • Free choice of frontend architecture / new frontend can be implemented in parallel
  • Backend and frontend can be developed individually and independently of each other
  • New areas can be rolled out continuously and made available exclusively for certain channels

Do you need support for your next web project?

Niels Langlotz
Web-Developer

Tel: +49 176 45 606 488
E-Mail: info(at)typoniels.de

I would like to use my project experience as a developer for your next project, just contact me.

Frequently asked questions & answers

The answer to the following questions may also interest you

In practice, separating the front-end and back-end of a web application and viewing them as independent systems has a number of advantages, including flexible and largely independent further development and the use of different technological substructures for the front-end and back-end.

1. frontend and backend do not know each other

This can quickly lead to structural problems within the application, which can be illustrated particularly well with the following examples. In scenario 1, an editor wants to link another article in the text editor, but the absolute link has not yet been determined and is only created when the application is generated due to the flexible frontend architecture. It is almost impossible for the editor to create reliable links here. In scenario 2, a dedicated search function is to be used in the application, whose database is fed from the back end, which can quickly lead to inconsistencies and a decrease in the usability of the search function, especially due to the decoupled display in the front end.

2. the editorial team has no live preview

Admittedly, with a rather high effort this limitation can be solved with a stand-alone application (shaddow frontend), which allows the editor to work comfortably in a simulated frontend, but usually the editor works in a minimalist editor without being able to test and control the reading flow in the real application. With classical systems, which do not separate frontend and backend, a simple control is possible here.

3. several systems have to be maintained

With each additional system, the infrastructure and the operational effort for maintenance and care also grows. This then usually requires additional employees.

However, it should not go unmentioned that a pure front-end application usually enjoys higher security and requires fewer resources in operation.