You need to be aware of what kind of resources you need to implement for your project. Headless CMS have limitations, especially cloud-based, in terms of customizations. You need to be careful not to fall into the trap and later not be able to have those features because the CMS is not extensible nor customisable. Sure, for some features, you can find a decoupled option (DAM, search systems), but the rest need to be very core. Those are possibly “missing in action” if you consider an average headless CMS. Traditional CMS-es might be perceived as a commodity after so many years, but the fact is that systems became quite powerful products with features like Search, Media management, Multi-language, Workflows, Scheduling, Versioning, Handling edit conflicts, Taxonomies, Custom content modelling, etc. In general, headless CMS-es do solve some things better than traditional, but they also have their own problems. You can always make badly performing client-side code :) But it is easy to forget that this approach by itself doesn’t guarantee good performance. The most popular approach is to use JAMstack and a headless CMS which can provide very good performance, but you can do a fast site with traditional CMS as well, leveraging CDNs, reverse proxies, caching strategies, etc. fewer server demands due to some of the complexity transferred to the browser.simpler caching between presentation (front) and application (content) layer.With headless CMS-es performance of the overall solution can be better due to the decoupled nature: This enables quicker changes across channels if you set up your content governance appropriately. This means it's easier to COPE - “Create Once, Publish Everywhere”, because it forces you to focus on reusable content and avoid delivery context. Headless CMS-es are multi-channel by nature. There are many good things about a headless approach. The DXP emphasizes that the system should be a focal point of various digital touchpoints, not just the web, providing APIs and tools for making those touchpoints. Gartner now has a DXP magic quadrant instead of CMS. There are more acronyms which are describing this kind of solution, but it looks like DXP (Digital eXperience Platform) is the winner. There might be a lot of technical debt which might get exposed through the API and cripple the usage and developer experience. But adding a sound and usable API is not a straightforward thing to do. This might prove important in the long run to keep existing clients but also attract new clients having features for both worlds. Some traditional vendors turned hybrid by adding APIs to provide a “headless” option. If you still just need a website you are probably better off with a more traditional CMS as you don’t need to develop the “head”. There is a clear distinction in capabilities between traditional and headless. That kind of product has all their features tightly coupled, focused only on the web as delivery and ill-equipped for multi-channel support. The complete opposites from the headless CMS-es are the traditional ones, especially those which don’t have any usable public API available. The term headless spilt to other markets as well, like DAM, e-commerce and similar, but in this article, we will focus only on CMS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |