CMS & DXP

Beyond the web, most companies now potentially need to publish content and services on a wide variety of channels: mobile applications, interactive terminals, connected objects, print, billboards, TV commercials, and virtual or augmented reality devices. And even if some channels still seem anecdotal, we need to anticipate their possible adoption by focusing on a long-term strategy. The headless CMS meets this need, first of all, because it decouples the management of content, stored raw, and the way it is presented on each channel. In addition, it allows to finely model these contents and to create new typologies. Better adapted to large projects, the headless CMS thus becomes a "content authority" on the scale of the entire company and all channels.

A DXP (Digital Experience Platform) can be defined as the ERP of digital. Concretely, it is a software suite comprising a headless CMS and components dedicated to e-commerce, marketing automation, content personalization, and even customer service or customer relationship management. However, these components are often supported with dedicated tools with which DXP must integrate. On the other hand, as in the case of classic or headless CMS, frameworks such as Symfony allow specific complementary developments to be carried out.

Beyond buzzwords, the notions of headless, micro-services, and serverless meet real challenges in terms of development, costs, performance, and sustainability.

The headless consists of decoupling the contents (exposed via an API) and the way they are displayed. It is one of the bases of the concept of DXP and it is the opposite of the CMS. The headless thus answers the stakes of multi-channel diffusion. If the channel is none other than the web and mobiles, DXP behaves like a classic CMS. It is also possible to create, based on a framework such as React, a Progressive Web App that will use a headless content management tool (such as Contentful's CMS or Ibexa's DXP).

The micro-services approach consists of renouncing monolithic software and preferring to aggregate, via APIs and frameworks, multiple services of disparate origins. In fact, micro-services are often macro-services such as headless content management, enterprise search engine, or PIM. We can thus choose the best component in each domain and spread their updates and replacements over time. It is also possible to entrust developments to different teams working in parallel. Basically, the micro-services approach allows us to better project ourselves into the future by responding to the challenges of project evolution, sustainability, and organization. Already widely adopted by publishers and open source projects, the approach is attracting more and more companies.

The serverless and its counterpart, the Jamstack architecture, consist in reducing web platforms to static HTML and Javascript pages placed at the periphery of the network, on CDN. The servers, essentially micro-services, are only solicited when the user invokes interactive functions, such as forms. The serverless thus answers to performance issues. However, more traditional technologies can be sufficient, as long as they are well mastered. The Jamstack services can be called by programs (JavaScript or PHP) or via APIs, possibly relying on micro-frameworks such as the one soberly named serverless.