Content Management Systems versus Content APIs

janit

Today the market is awash with options available for developers to consume content using the APIs. Some go as far as describing their offering as a CMS without the bad parts, where as some choose to provide content using a data centric API platform.

With RESTful interfaces being a part of many developers every day life and, it's good to have a view on the advantages and disadvantages of platforms used to serve data and content:

While decoupling your front end using a clean REST API / GraphQL / Falcor is an advantage for many uses. But in reality managing a website is much more than just content management. If you use only a content API, then it's likely that you'll need to build something to manage layouts and provide common functionality like feedback forms, etc.

When the content we have accumulated becomes increasingly complex and a semantic content structure becomes a true competetive edge, will the pure API players have an advantage over Drupal and other traditional CMSes? While you can tweak your Drupal architecture with CQRS/ES to enable amazing things, there is still a lot of baggage and shoehorning in that. It's a long way before Drupal becomes truly API first and the new comers have an advantage here.

In this talk we will analyse the different approaches to CaaS and provide insight on how to identify when your customer should use a CMS and not a Content API - this applies to both headless Drupal as well as using a service like Contentful. Moving forward a GraphQL or JSON API interface looks to be the de-facto standard for decoupling with headless CMS:es.

Register NOW

Session Track

Horizons

Experience Level

Intermediate

Drupal Version