What Every Developer Needs to Consider About Headless CMS - Primacy | Blog Primacy | Blog Skip Navigation Back

What Every Developer Needs to Consider About Headless CMS

The concept of the Headless CMS has steadily gained mainstream industry attention in the last year, moving beyond developer circles in 2015 and into a report from Forrester in 2016. Might 2017 be the year that Headless CMS products start to gain more traction with larger enterprise implementations? The recent post The State of the Headless CMS Market suggests that 2017 will be the year of the Headless CMS and vendors of such products think the same.

What is a Headless CMS?

Most simply put, it is an “API First” CMS which uses HTTP and JSON for content delivery. On the backend it provides a web-based content authoring environment, which non-technical content authors use to edit and maintain content.

Contentful and Built.io are the early leaders in this market. Gather Content is arguably a Headless CMS although it’s typically used as an intermediate step between CMS’s for content migration and aggregation. Each of these are SaaS cloud based systems. There are smaller niche systems which support on premise installation. Common open source CMS’s like Drupal and WordPress have plugins which support JSON-based web services for accessing their content. And many commercial CMS platforms provide similar APIs out of the box, or with minimal configuration to enable, or sometimes requiring an additional supported extension.

Why Use a Headless CMS?

The most common justification is when you have several different uses for your content such as:

1.    One or more web sites

2.    Native mobile applications

3.    Kiosk or desktop applications

4.    Other channels or external partners

If your organization is evaluating adopting a Headless CMS project and architecture, there are many considerations to have in mind.

1.    The Headless CMS puts all the power in your development team’s hands to use any technologies or frameworks for consuming and displaying content. This also means that your team is fully responsible for maintenance and upkeep. If there are issues or bugs with your website, it’s on your team to support it, the Headless CMS vendor will not support your implementation.

2.    Expect a pure Headless CMS like Contentful to require a lengthy implementation time that will require your team to write a substantial amount of code. If all you need is a CMS to manage content for a web-delivered responsive website, a Headless CMS is probably overkill and will actually slow time to market rather than speeding it up.

3.    It requires separating “content” from “content presentation” – to think about content as just content, not pages or modules on pages. On the surface this sounds simple, but in practice this level of abstraction is extremely difficult to achieve. Depending on the number of consuming applications for your content, expect your content architecture exercise to be significant.

4.    Presentation rules often seep into the CMS. In Primacy’s experience we have found the need to introduce “content behavior” rules into our CMS implementations. For instance, we typically have a flag to indicate if a piece of content is indexable or searchable. Additionally, in order to provide a better user experience for content authors, our content templates have fields which imply a display rule or display position, e.g. a field called “Page Header”. This may help content editing but does not make the content device or display agnostic.

5.    Headless CMS products as noted earlier tend to be SaaS cloud-based systems. That is an important consideration, especially when security and privacy are a fundamental requirement or when you are in a highly regulated industry such as healthcare.

6.    Should you need to support a multi-lingual implementation, your team is on the hook for language detection and implementing content fallback, etc. Expect more implementation effort for multi-lingual scenarios. Many traditional CMS’s provide multilingual support out of the box.

7.    For your website, site search will be more challenging to implement. You will need to evaluate if utilizing custom Google Site Search, a search appliance, or a third party commercial search platform such as Coveo is necessary. If you were to utilize an open source platform like Lucene or Solr, expect a custom site search implementation to take several weeks or more to complete and test.

8.    The backend content authoring is not turnkey, it requires setup and configuration to prepare for all the various “types” of content you’d have, e.g. blog posts, press releases, events, landing pages, etc. This is not typically a developer exercise, but having your developers and technical lead involved ensures the front-end sites, applications and devices are built correctly and efficiently.

9.    Expect integration of 3rd party data sources or 3rd party content sources to be more time consuming and challenging. In nearly every CMS build Primacy has done there is a need to integrate data from 3rd parties either natively into the CMS (using the CMS’s content import APIs) or to partially integrate such content with the CMS with a connector API.

Headless Hype or Practical Solution?

Headless CMS products certainly have their place, and do have cases where they are appropriate. At the same time, the hype may outweigh the practicality for many situations. In order for these products to gain traction and wider acceptance at the enterprise level, the vendors of such products will need to provide productivity tools and SDKs for many common server-side or front-end platforms. Until that happens expect these products to remain in the toolset of niche vendors and development teams.

Additionally, expect the traditional CMS platforms to continue to pivot and provide Headless CMS capabilities out of the box. If nothing else, vendors like Contentful are forcing traditional CMS vendors to add capabilities. Before adopting use of a Headless CMS make sure you fully evaluate all your options and carefully consider the pros and cons.

By using Headless CMS, note that you might be bypassing the intended CMS architecture for the presentation layer. Many CMSes have put as much or more thought into the authoring tools as they have into the content repository and API.  By going headless, you would be circumventing the authoring tools, and thus not realizing much of the value offered by purchasing a 3rd party CMS.

avatar
Author: Jon Scott-Sheldon

Jon’s started work as an Internet Developer back in 1996, when Netscape Navigator 2 was the “it” browser, and CGI-BIN was not a dirty word. He spent his early years implementing perl and cgi based web applications. By the late 1990’s he jumped into the world of Microsoft and development with Active Server Pages, VB6 ActiveX, and SQL Server. In the early Aughts he moved to primarily writing code using the .NET Framework and asp.net, as well some PHP development with PostgreSQL, and java enterprise development with IBM WebSphere, which he continues to use to the present day. Most recently he’s joined the mobile revolution and develops for Blackberry and IPhone devices.


Published March 2017

Category Technology

Comments (1)
avatar
Mario

Thanks for sharing your experiences with headless CMS’s regarding the pros and cons! It was helpful.