Why not both in one?
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
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:
Pros:
- 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
Cons:
- You need one more layer to be managed somehow — presentation (so you probably need infrastructure: version control, web server, etc.)
- Isolated costs: CMS itself payment, developer’s job payment, infrastructure payment likely
- 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
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:
Pros:
- 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
Cons:
- 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?
This article was originally published on the APIQ CMS blog.