Headless CMS or Coupled (database-driven) CMS? You’ve probably heard about this mess before (there’s a lot of articles on the internet) and want clarification on what CMS software to choose and especially in which case. The last one is the main point: your choice completely depends on what’s your content for.
Headless CMS — content management system that assumes only content layer, without representation layer. You create and organize content for later delivery to your website, mobile app, anything else.
Therefore, pros and cons obviously will look like this:
Separation of content and its presentation
Independency from presentation level: choose any frontend serving technology you like — static website generators, plain HTML and JS, web frameworks
Single place for your content: use it on any number of websites or mobile apps
Developers like APIs — not an obvious advantage, but makes sense because not every developer likes to learn special templating language
You need one more layer to be managed somehow — presentation (so you probably need infrastructure: version control, web server, etc.)
More “expensive” developer: pretty clear that developer should be more qualified and will spend more time
Could take time: you need to learn API, integrate with it, debug and test
Coupled CMS — content managing system that handles both layers: content and presentation. These are old-school players like Wordpress, Drupal or similar. The idea is pretty similar — your website should be completely served by one system.
And here pros and cons for such type of CMS:
Solid system: content and its presentation (HTML) coupled together
Clear costs for website development: one system — one account — one payment
Low entry threshold for developers
Quick result: “API” already tested and integrated, you’ll see changes immediately
Dependency on presentation layer: possibilities are limited
Website-only content (in case of API absence): you can’t use the same content in mobile apps of somewhere else
Learning for developers: they would prefer favorite language over special one
As you may notice, some pros of first are cons for second and vice versa. Depending on your business tasks and the list above you can decide which one of these CMS types to choose. So these systems look like counterpart for each other. What if just to combine benefits from both eliminating all disadvantages by the way? Sounds interesting for me, and may be a good reason for researching and implementing in APIQ CMS.
What do you think about this possibility and does it make sense for you?