Decoupled body parts: headless CMS and SilverStripe

What’s headless CMS? Do you need to get an axe? If you’re developing a rich web application, it’ll be a no-brainer to go headless with SilverStripe!

Web Content Management Systems (CMS) have traditionally held two roles: managing content and rendering the website that surfaces this content to your audience. Combining these has distinct advantages but falls short in the modern landscape of creating multi-channel digital experiences. Content underpins these experiences and managing it efficiently becomes more important than ever. This post describes the challenges every modern CMS faces, and where SilverStripe CMS fits in this picture.

What’s headless? Do I need to get an axe?

Fortunately, we’re not raising the digital undead! The “head” refers to the presentation channel (“frontend”), which is usually a website or web application. This is contrasted with the content management and publication abilities (“backend”). When your only presentation channel is server-rendered HTML, a monolithic solution provides the least implementation friction to teams. But once your frontend becomes a mobile app, renders content via JavaScript, or exposes content through multiple channels, you’ll want more flexibility from your CMS.

This is where APIs come in handy: structured content (JSON/XML rather than HTML) allows all kinds of frontends to consume it. At its core, what makes a CMS headless is its ability to manage and deliver content in a presentation-agnostic way to other systems, without being directly involved in the presentation itself.

Why should I care? I like my head on the body!

You don’t have to be a mobile native app developer to care about the benefits of going headless. Even a complex website layout can benefit from this approach. And there are many fringe benefits, which aren’t necessarily technical.

Cross-platform publishing: Your CMS doesn’t need to know how to feed data into a mobile app, or work with a voice assistant.
Performance and scalability: Smart frontends consuming stateless APIs tend to lead to a more streamlined user experience. Views can rely on complex display rules (e.g. for personalisation). Keeping this complexity on the frontend allows APIs to be cached with simpler rules through fast intermediary layers like a CDN, and stored in simpler infrastructure components.
Fast frontend iterations: By relying on a well-defined API on a separately deployed CMS backend, frontend teams can move at their own pace. They’re independent of backend deployments, which tend to be slower due to infrastructure and organisational constraints.
Personalisation: Digital experiences are rarely created from one content source alone. Your website customer might have purchased products over the phone, or left reviews at partner sites. Analytics and personalisation engines are becoming just as important as content management, and a flexible content delivery allows combining these information streams in the best tools for the job.
Future proofing: Your website or app implementation is more likely to transfer to another CMS backend if content is cleanly decoupled. Consequently, your CMS is going to hold up better when your customer needs to add other channels to a traditional website.

How does SilverStripe fit in?

Is SilverStripe the slow zombie or resilient survivor in this headless world? While it comes from a monolithic background, we believe that the inherent flexibility of SilverStripe Framework and CMS will allow for this emerging use case, alongside more traditional website builds.

Separation of data from presentation: Due to its Model-View-Controller (MVC) background, separating presentation concerns from your data has always been best practice in SilverStripe. A gallery module might have default templates to render your collection of images as HTML, but the backend UI and storage can be used independently, and exposed through APIs just as easily.
Strong relational data management: Just because a CMS is headless doesn’t mean your business domain gets simpler: SilverStripe is great at managing relations between your content, through taxonomies and associations — with interfaces and developer APIs optimised for this use case.
APIs: While the term “headless” might be new, SilverStripe websites have exposed structured data for a long time already. There are various REST modules that are heavily used for creating mobile and single-page apps. SilverStripe 4 alpha4 has added a GraphQL API, too.
Decoupled core modules: You only need to use SilverStripe CMS if your use case requires “pages”. For other content structures, the SilverStripe Framework comes with a more lightweight UI and feature set (ModelAdmin). In SilverStripe 4, we’ve also separated out asset management, allowing you to opt out if you just require a CMS for managing text-based content and simple uploads.
Powerful interface: The ability to influence the CMS authoring experience is one of the major attractions to SilverStripe. The strong ecosystem of modules have been honed by years of hands-on user feedback from CMS authors: workflow, translations, content review, search, campaigns, reporting.

Where are we … headed?

From a library perspective, SilverStripe is going to continue its decoupling strategy. For example, we want developers to harness the power of the SilverStripe ORM with data edited by the SilverStripe CMS, even if they’re choosing to use a different technology for serving requests (e.g. full-stack frameworks like Laravel or micro-frameworks like Lumen) or surfacing APIs with SilverStripe-authored data.

While APIs and structured data have always been part of SilverStripe projects, we’re gearing up to make them first class citizens —one of the major features of the upcoming SilverStripe 4 release is a partial rebuild of the CMS interface as a single-page application (read more about our move to ReactJS). This requires core support for read/write APIs, which we’re achieving with a new GraphQL module (in addition to community-supported REST modules). The GraphQL standard is an alternative to REST APIs aimed at smart frontends (JavaScript, mobile apps, etc), which need an expressive API layer with JSON payloads. Its focus on data relationships (“graphs”) suits any type of model structure created through SilverStripe, and leads to more powerful frontend abstractions like inlining multiple models in a single request. It is self-documenting and strongly typed by default, making it a great choice for collaboration with other API consumers. While these efforts are in early stages, we’re hoping to create an official SilverStripe Content API through GraphQL for built-in types like pages or assets, and enable more interoperability with other toolsets.

CMSWire has forecast that 2017 will be the year of headless CMS. An adaptable framework positions SilverStripe well to take advantage of this. Running “headless” with one or more decoupled frontends is an extra tool for an increasing number of use cases. The ability to render HTML for websites is of continued importance for the web as a whole. Every project team will need to consider the complexity and flexibility tradeoffs of running separate tools for frontend and backend which each only solve half of their problem. If you’re developing a rich web application, it’ll be a no-brainer to go headless with SilverStripe!