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.

Ingredient	Bakingtime	Bakery	Baking instructions
Cookie secret ingredient	1 year	TYPONiels HTML	Saves your consent to using cookies.
TYPO3 Users (Login)	session	TYPONiels HTTP	Assigns your browser to a session on the server.

Ingredient	Bakingtime	Bakery	Baking instructions
User ID	13 months	Matomo HTML	Used to store a few details about the user such as the unique visitor ID.
Referrer	6 months	Matomo HTML	Used to store the attribution information, the referrer initially used to visit the website.
Session of the user	30 minutes	Matomo HTML	Short lived cookie used to temporarily store data for the visit.
Data of the session	30 minutes	Matomo HTML	Short lived cookie used to temporarily store data for the visit.
Temporary Data Object	30 minutes	Matomo HTML	Short lived cookie used to temporarily store data for the visit.
AdSense Audit	3 months	Google HTML	Used by Google AdSense to experiment with advertisement efficiency.
AMP Token	1 year	Google HTML	Contains a token that can be used to retrieve a Client ID from AMP Client ID service. Other possible values indicate opt-out, request in progress or an error retrieving a Client ID from AMP Client ID service.
DoubleClick identifier	2 years	Google HTML	Used by DoubleClick (Google Tag Manager) to help identify the visitors by either age, gender or interests.
Survey Invitation	365 days	Hotjar HTML	Hotjar cookie that is set once a visitor interacts with an External Link Survey invitation modal. It is used to ensure that the same invite does not reappear if it has already been shown.
Survey completed	365 days	Hotjar HTML	Hotjar cookie that is set once a visitor completes a survey using the On-site Survey widget. It is used to ensure that the same survey does not reappear if it has already been filled in.
Survey (FeedbackMessage)	365 days	Hotjar HTML	Hotjar cookie that is set once a visitor minimizes an On-site Survey widget. It is used to ensure that the widget stays minimized when the visitor navigates through your site.
Feedback form minimized	365 days	Hotjar HTML	Hotjar cookie that is set when a visitor minimizes or completes Incoming Feedback. This is done so that the Incoming Feedback will load as minimized immediately if the visitor navigates to another page where it is set to show.
User identifier	365 days	Hotjar HTML	Hotjar cookie that is set when the customer first lands on a page with the Hotjar script. It is used to persist the Hotjar User ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
Letzte Aktivität	session	Hotjar HTML	This should be found in Session storage (as opposed to cookies). This gets updated when a visitor recording starts and when data is sent through the WebSocket (the visitor performs an action that Hotjar records).
TLD test	session	Hotjar HTML	When the Hotjar script executes we try to determine the most generic cookie path we should use, instead of the page hostname. This is done so that cookies can be shared across subdomains (where applicable). To determine this, we try to store the _hjTLDTest cookie for different URL substring alternatives until it fails. After this check, the cookie is removed.
Feedback User Attributes	session	Hotjar HTML	User Attributes sent through the Hotjar Identify API are cached for the duration of the session in order to know when an attribute has changed and needs to be updated.
User attributes (Cached)	session	Hotjar HTML	This cookie stores User Attributes which are sent through the Hotjar Identify API, whenever the user is not in the sample. These attributes will only be saved if the user interacts with a Hotjar Feedback tool.
LocalStorage test	365 days	Hotjar HTML	This cookie is used to check if the Hotjar Tracking Script can use local storage. If it can, a value of 1 is set in this cookie. The data stored in_hjLocalStorageTest has no expiration time, but it is deleted almost immediately after it is created.
Page limit	30 minutes	Hotjar HTML	This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's pageview limit.
Session limit	30 minutes	Hotjar HTML	This cookie is set to let Hotjar know whether that visitor is included in the data sampling defined by your site's daily session limit.
Session Process Flag	30 minutes	Hotjar HTML	This cookie is used to detect the first pageview session of a user. This is a True/False flag set by the cookie.

Do you need support for your next web project?

Frequently asked questions & answers

What are the practical limitations of this approach?