Universal Editor for Headless CMS: Part 1, General Thoughts
![Anton Tishchenko](/assets/blog/authors/anton_circle.png)
![Cover Image for Universal Editor for Headless CMS: Part 1, General Thoughts](/assets/blog/20240722-universal-editor-general-thoughts/cover.png)
There are tons of different content management systems. All of them are quite different. They are written in various languages. They have different capabilities. They could be free, cheap, or expensive. But almost all modern CMSs have one in common: they are advertised as headless.
“Headless CMS” became a buzzy word. Different CMS vendors add different meanings to this term. For this post, let’s use a simple meaning: Headless CMS is the CMS that separates content from the presentation.
Was the movement to Headless architecture good? There could be different points of view on this question. On the one side, moving to headless architecture brings many advantages: freedom for architecture, flexibility for developers, performance, lower time to market, scalability, smoother upgrades, easier maintenance, eliminating vendor lock-in, and lower prices. On the other side, we lost the WYSIWYG editing.
You may say that, no we didn’t lose it. Enterprise CMSs still have it. You can still edit your page in Sitecore, but it is now based on headless architecture. If you need rich editing capabilities, CMS vendors usually have additional products, like Contentful Studio, Sanity Studio, Universal Editor for dotCMS, etc. But with these products you lose advantages that you get with headless architecture: you get vendor lock, get less freedom and flexibility for development and architecture, and time to market is again increased. And the more advanced is vendor editing product, the less headless solution we get.
Can it be changed? We have more or less standard things on both ends. CMSs provide REST or GraphQL API to receive data. Frontend is implemented with React, Vue, Next, Nuxt, and Astro. Could the editing studio also be standard?
I think, yes. There will be only a few requirements for CMS:
- API to get, update, and find content
- Authentication via OAuth or JWT
- JSON data type to save the page layout
I am committing to try it. I will start with 2 CMS: Contentful and Strapi. I chose them because they are quite popular and usually used without any “studio” additions from my experience. Stay tuned for the next posts. I will share my experience and thoughts.