Perch Runway 3 as a Headless CMS

The primary end goal for a web content management system has always been the output of HTML to a web page. Content goes in, and all being well, HTML comes out the other side. That’s likely to continue to be the primary way of working for a web CMS for a long time to come, and maybe forever.

That’s not the only way the web is used, however, and in recent times there as been a growth in both JavaScript applications and native mobile apps that pull their content from the web. Rather than using HTML as the conduit for content moving between the backend and the client, both these use cases frequently rely heavily on JSON.

One good way of dealing with those sorts of projects is to use a headless CMS.

What is a headless CMS?

Sometimes called a decoupled CMS, a headless system seeks to make an architectural separation between the content and the presentation. Whereas a lot of traditional web CMSs create a tight coupling of the content you enter and the HTML/theme used to output that content onto a page, a headless CMS deals just with the content and not the presentation. No themes, no layouts, just content.

A great example of tight coupling of content and presentation is our old nemesis the WYSIWYG editor. Those editors bake HTML right into the content – if you want to use that content without HTML, you’ve then got a difficult job trying to clean it all up.

Ask a headless CMS for content and it’ll give you raw data, not a web page. This raw data is then used by another layer in the system (such as a JavaScript app running in a browser, or a native app running on a phone) to generate the presentation layer that the end users sees.

Going headless

If you’re an experienced Perch user, all this will be sounding very familiar. Perch and Runway are very deliberately designed to keep content and presentation cleanly separated, and in a very practical way you can use Perch and Runway right now to output a JSON or XML document just like a headless CMS might.

This makes the addition of headless operation a natural complement to the functionality already provided within Runway. To work really well, it needs to offer a few key things.

The first is interrogation endpoints to enable your client app to find out what content is available. This basically fulfils the role performed by traditional navigation menus on a website. So the first step is to provide this navigation in a data-driven form.

The next element is to implement a structured system of routes and views to make putting together a headless project much more straightforward. You shouldn’t need to design a whole new architecture to get started with a few headless requests, so Runway will define a workflow to make this quick and easy.

Views for miles

Just like anything when it comes to content management systems, there are lots of different ways a headless CMS could be implemented. One of the ways it can be done is to provide a direct API to the entire system that can be queried from the client with a series of requests. The client decides what content it needs, asks for it, and then displays it. That can be great in some circumstances, but that’s not quite what we’re going for here.

In Runway, you set up a series of views to return the data you want to expose to clients. The data in those views can be subject to business rules (e.g. don’t show items with a future date) and can either be resource-focused (return all the latest news items) or application-focused (return all the content needed for the home screen).

This approach has some key advantages which fit how most people work with a Runway-based project. If your view only returns the data you want to display, your client application can be very light weight. Without needing to implement querying and filtering on the client, you also don’t need to worry about authentication for basic content retrieval. From the server side, view based queries are easy to cache, making your requests nice and fast.

What it is not (yet)

In this first phase we’re implementing view-based requests. There’s no authenticated general querying API, so the client can’t decide it wants some data that hasn’t already been prepared in a view on the server.

This is also a read-only API for retrieving content for publishing. Write actions are likely to follow in the future, but we’ll wait and see how headless mode is being used in real projects first.

The icing on the cake

Where we think this will really excel is in those projects where there is a requirement for a mix of traditional web-based content management and a need to serve other types of client, too. One system can be used to manage all the content, but with multiple output platforms.

You might have a website publishing your content, but also have a mobile app that wants to display it too. With the new headless mode in Perch Runway 3, you should have a great solution for doing just that.