I was going to start this article with the question: do you still remember Microsoft Access? But then I found out that this boil of a “database” system still exists.

In my former life as a developer, this pseudo database product caused me so much pain because it was constantly abused for uses not really feasible for this kind of product.

MS Access is a perfect product for Windows users managing their catalog of movies or contacts, collections of whatever kind or, to say it in a simpler way: for local personal usage of low volume data. The great thing about Access was always the user interface, making it possible for less skilled people to create and manage “databases”.

Because this was so easy and because Microsoft was once the dominant player on PC back office and desktop systems, I have seen abuse of this little personal data management system by serving as a back end for the then dominant client/server architectures. Of course it didn’t scale, not to even start talking about data integrity, safety and the hell of driver issues - to be fair this was always a pain with all Microsoft products, even those on the “enterprise“ level.

MS Access was also used a lot for doing data migrations - transferring data from one database system to another database with MS Access serving as an intermediary. This worked as long as data structures and content were simple - I remember myself writing a simple program with Borland Delphi to help an external “expert” consultant with data migration for a new ticketing system after he couldn’t manage to import a certain column value into Access from a Microsoft(!) SQL server database.

So where’s the connection between a headless CMS and MS Access?

Of course there is no real connection - as I hope no one is so insane to base his cloud based product on a MS Access backend :-)

But after seeing a demo video of a popular “headless” CMS system on YouTube, I instantly asked myself two questions:

So basically it looks like those headless CMS systems provide interfaces for easy data structure creation and entering data into simple database structures. I doubt that there is a way in this software to easily add complex data validation, fine grained security, integrations of third party systems or customization of any other kind.

Does it scale?

Hopefully performance these days will not be an issue any longer when accessing data stored in a cloud based back-end. But what about the performance of concurrent data editing, roles and group permissions, changing end extending data?

The audience of a true headless CMS

For me, a true headless CMS makes sense primarily for developers who are not willing or capable of managing more sophisticated back-ends - remember the analogy to MS Access. And in some cases, data structures and the amount of content may be so limited that there is no need for something more complex.

It can also make sense if you want to produce something simple really quickly and you don’t need to care about extensibility and the future use of your investment.

In my opinion, even the available interfaces for managing back-end data are for power users only, definitely not for the the average end user.

As a summary you could say, the headless CMS is fun for developers but not for the people working with the content on a day-by-day basis.

How to avoid the MS Access trap, protect your investment and still have a system that is fun to develop with

When you speak of a “headless CMS” these days you often mean a CMS with very limited capabilities that normally still needs a lot of development to be able to catch up with full blown CMS products. The people marketing those products often do a good job of making developers, customers and investors drink the “Kool Aid”.

But what’s stopping you from using a “traditional” full-featured CMS system in a headless way? Every sophisticated product should provide you with the ability to have interfaces to the managed content out of the box.

A headless CMS is comparable to a simple data store with interfaces for external clients, so what’s the big deal?

Magnolia CMS out of the box provides several standard ways of providing interfaces to content stored in its repository. You can use the built-in REST interface or include some of the solutions already existing in the eco system. And because you can use Java if you want, you can create whatever simple or complicated logic to provide information to external clients.

In contrast to a more basic “CMS” you can make use of your valuable data in more than just one way by using the sophisticated toolset and user interface your “traditional” CMS provides - at least in the Magnolia case. An external client may just be an addition to your ecosystem and can be developed as fast as with any headless CMS you find on the market - and it provides the same amount of “fun” to developers who can use whatever cool JavaScript technology of the week they love so much.

It’s even a real world use case to have applications, e. g. build with Angular, that can be used stand alone or as a selectable component within Magnolia CMS. And in this case, end users are able to manage the integration themselves with an interface and without the need for a developer.

To summarize…

Of course there are valid use cases for using a pure headless CMS system - initial ramp up time is cut short and many developers like the built-in freedom they have when designing the client side solution.

On the other hand, a headless CMS system is just a very limited system sold by great marketing and IMHO should never serve as an enterprise level back-end platform to protect long term and strategic investments by companies. And once the headless vendors catch up with features (if ever), then it won’t be a headless CMS any more…

So be clever and avoid the “MS Access trap” that looks like a good and fast solution in the beginning but then falls flat after usage and features increase. Better to invest more money in a platform-like product that can be extended and integrated well to fit best with the needs of your organization.

Just my 2 cents gained after some decades of experience…

This post has also been published on the Magnolia Blog.