Powered By CMS

This talk aims to introduce the concept of a Headless CMS to the audience, in a platform neutral way. CMSes have traditionally coupled the content with the presentation of that content. While this worked in the early internet, where desktop browsers were the main consumer, this model has started to crack as the internet evolved.

The first crack in this model is the “host it yourself, and install lots of plugins model” of popular CMSes. Since the content and presentation are tightly coupled, it’s very difficult to make significant changes in the look and feel of the site without installing a plugin or layout, which is often error prone.

The second crack in the model is that IT teams have evolved and specialized. Today you might have programmers who specialize in the Web (HTML + CSS), and others who specialize in data, and getting that data to scale. The traditional CMS model requires a team who is a blend of these two talents, which is significantly harder to hire and maintain. This team also has to understand concepts of security, scaling databases and caches, and other concepts which are peripheral to your business.

Finally, today’s modern web has 100s of formats. From Facebook’s instant articles, to google’s AMP. The traditional model of keeping your content in HTML does not scale to these formats, and often there is no way to get the control you need to adapt to each format.

Headless CMSes is a term used to describe a CMS that is API-only, ie, there is no front end shipped by default. This split provides a number of benefits which be discussed in this talk, including the impact on the IT team.

This talk will partly be based on Quintype’s move to a headless CMS model.

Outline

The talk will go something like this:

• Brief introduction to the constraints under which traditional CMSes were formed
• Drawbacks of the model
  • The 100s of forks and plugins
  • Dedicated teams for database management required in non-tech companies
• Brief intro to the de-coupled nature of headless CMSes
  • Ability to have separate teams
  • Easier to scale with finer grained cacheing (and helping you save money)
  • Have multiple versions of the site powered by by the same store of content
  • Use the same API to power mobile apps, Facebook Instant Articles, RSS feeds, etc...
  • Hire the team you need: more front end developers, and outsource the data management
  • Your teams can move at their own pace. We’ve seen that teams working on front ends typically move faster, and have more churn, while those that touch data are slower
  • Better Security, as your main domain is not where your editor is located
• Cover a few of the drawbacks of the headless model, and how they can be overcome
  • The WYSIWYG model is lost (but we can add preview functionality)
  • Split codebase
  • Changing the data model is more difficult

Requirements

A vague understanding of how CMSes work

Speaker bio

Random things from a random person

Links

• https://www.youtube.com/watch?v=atUdVSuNRjA