Have you heard this term going around? It’s quite in vogue. It’s very related to The Big Conversation™ on the web the last many years. How are we going to handle bringing Our Stuff™ all these different devices/screens/inputs.
Responsive design says “let’s let our design and media accommodate as much variation in screens as possible.”
Progressive enhancement says “let’s make the functionality of this site work no matter what.”
Designing for accessibility says “let’s ensure everyone can use this regardless of their capabilities as a person.”
A headless CMS says “let’s not tie our data to any one way of doing things.”
A “regular” CMS gives us three things
- A way to store data
- A CRUD UI
- Ways to display the data
A “headless” CMS only shares the first two
- A way to store data
- A CRUD UI
- An API to the data
The “head” (that we are chopping off! eww!) is the display or “view” part of a CMS.
TL;DR graphic
Tech comparison
Perhaps in a regular CMS, the only way to get at the stored data is functions it provides. Like:
<?php MyCoolCMS->get_post_data(12); ?>
<h1>
<?php echo post_title(); ?>
</h1>
<?php echo post_contents(); ?>
If you want at that data, the only way in is using the functions it provides. You could probably write a view that outputs like an API. Or you could write queries into the data storage to get what you want. But those things aren’t “first class citizens” of the CMS.
In a headless CMS, access to that data would be a URL endpoint like:
https://api.our-stuff.com/posts?id=12
Which would spit out:
[
{
id: 12,
title: "Post Title",
authorName: "Chris Coyier",
dateCreated: "2007-07-03 10:42:02",
postContent: "<p>A long time ago...</p>"
}
]
Or something like that.
The URL structure and query params and all that would be up to the CMS and in all likelihood be “RESTful”. I’m not qualified to give advice there, but it’s a pretty easy thing to web search and read about, as well as look at reference implementations.
You don’t even know what the next THING is.
Maybe it’s a little implant in your wrist that projects a screen onto your forearm. It’s super popular. Everyone is getting one. The company that makes it allows people to write apps for it, but it doesn’t have a web browser. It’s got network access though.
So now, if you wanted to, you could use whatever system they have set up to write an app, use the network access, and get your data over to it to use.
You didn’t have to know this new thing was coming along, your data is already ready-to-travel.
Just because it’s an API doesn’t mean the views using it are client side
Oh great, more sites that only work with JavaScript.
Nah. Server side code can read and digest data from an API just as well as client side code can.
Can you use a “regular” CMS as a “headless” CMS?
Sure.
We have a tutorial on the WordPress REST API that might be of interest.
WordPress is certainly a “regular” CMS in that is absolutely has the concept of views, but it’s not required that you use those views. If you wanted to digest WordPress entirely through the API, that’s possible.
Listen to a whole conversation about this
Dave Rupert, Jeff Eaton, Matt Dennewitz and I talked at length about this on ShopTalk.
Are people actually doing this?
Yes. I’ve seen some implementations and hear tale of widespread usage across major publications. I’m not sure I’m cleared or qualified to explain them though.
Are any of you doing it?
Yes I’m very much on board with this approach (so much so my own pet project sites are being rebuilt this way).
For so long I’ve been using a CMS to manage my site which was just fine, but now I’m getting to the point where I don’t want to be limited by the built in view component in the CMS and write my own UI layer (possibly in a completely different stack e.g. a .net CMS with a Node UI layer?)
With REST microservices becoming very prominent it wouldn’t surprise me if we end up seeing more CMS going this way.
Yes, I’ve been talking about this very subject for quite some time (see http://laravel.io/forum/05-13-2014-api-first-cms). I know the KeystoneJS guys use their CMS for all sorts of applications, web, mobile and IoT. I’m also investigating about possibly exposing not just a REST API, but a realtime API via websockets. Very interesting stuff.
Found this headless CMS, which seems pretty cool (based on 5 minutes worth of research) – https://www.contentful.com/. Seems like you would never hit your limit on API calls (for free plan), assuming you are caching your calls to the service.
I used Contentful on a recent side-project as an experiment. I connected the API via a Middleman Static-Site extensions. Therefore I was able to get the benefits of speed and flexibility of a static site while geting the GUI of the Regular CMS. This is what Vox’s team, Carrot Creative use.
However, I found it poorly documented to set up and it took a lot of trial and error. Then Contentful said I had too many API calls and so I had to shut down the site. The paid version is $99 a month so hopefully the price comes down or a cheaper, competitor enters the space.
Carrot goes over their cool process here: https://www.contentful.com/blog/2015/04/28/webinar-contentful-roots-static-sites
There already are cheaper alternatives http://alternativeto.net/software/contentful
a nice example here https://prismic.io/quickstart
We evaluated all of these I could find.
http://www.contentful.com
http://www.prismic.io
http://www.osmek.com
http://www.cloudcms.com
http://www.webhook.com (not quite, but data is in Firebase so could be used that way)
but ended up building a small CMS SPA on top of Firebase because it fit our expected use-cases way better.
https://github.com/tivac/crucible/
It powers https://competitive.guildwars2.com, it was pretty great overall.
Very cool. Good job. Starred. =)
For the “average” website, I can’t see a headless setup adding any value, just more complexity. If you’re NPR where you have multiple servers feeding content to affiliates, hell yeh a REST API is going to be invaluable. Or if you need to serve content into an app. Sure, use REST. (There’s other technology too.)
But for the rest of us? The web is slow enough as it is, do developers really need another abstraction layer—especially one as verbose as HTTP? If your view layer is so awful that it can’t grab what you need, based on what you model gives you, REST really isn’t going to help you.
The real headline about headless IMO is it gets people thinking about decoupling their content from the presentation layer. ( That’s the big win. To paraphrase Noah Stokes—I think it was an episode of ShopTalk—he mentioned a CMS is really just an interface to a database of some kind. How we access each individual piece of data is becoming more and more relevant today with multiple screens, etc.
A decoupled setup gets you thinking about how you’re actually going to access that data. Much like mobile first got us thinking about preparing content for small screens, we can still make a great desktop-first website—provided you care about how your site is going to show up on mobile. The same is true of a CMS.
If your CMS doesn’t provide you tools to break content into chunks, get rid of the CMS. I love tools like Craft because that’s exactly how they work.
CMS like WP have very little notion of that. You get a title, maybe a featured image. But then you have this wall of text called the body where authors are supposed to use their evil WYSIWYG to format it. If you wanted to get every image in a post, you’d need to grep through and find them. What about finding other posts that used the same image? Harder than it needs to be.
WP is really putting the cart before the horse here. A REST API is great, but you need more built-in field types to really take advantage of it. So we rely on tools like Advanced Custom Fields and Pods to add more fields to help us break that content out of that content blob. If you’ve ever read or watched Karen McGrane, she is very vocal about this—the blob vs the chunk.
Complexity of the app really depends on the developer. I think an advanced developer finds a full CMS more complex (maybe a better word is “burdensome”), because of the need to learn proprietary functionality. However a headless CMS is easy. Just install it, and then build the app you want. I guess if a dev isn’t familiar using a CURL lib (if building a server-side app) or AJAX if building a SPA app, then the full CMS is easier, because they can pick a theme, and then tweak.
As far as performance, I think it isn’t relevant. Just like anything else, it is up to the skill of the developer. 2 developers can build identical WordPress sites, and one will be fast, and one will be slow, because one developer is more advanced than the other. There is no need to make an extra HTTP request if caching is involved.
I think there is a large population of users building these SPA apps (look at how Angular has blown up). You can use a DAAS (like Firebase), but thats really just a database… You still need to build the management side of things (which is boilerplate). These headless CMS’s really help fill that void for a lot of developers. Build your site, and don’t worry about the redundant boilerplate.
@ Mike: Are we talking about apps or websites?
I think you’re underestimating how much work it really takes to build something capable if you think headless is easy.
I come from client services land so your mileage may vary but it sounds like you haven’t spent much time with clients if you think a good backend UI is just boilerplate. People like the NYT and NPR have spent years making sure these systems work to their needs.
If what you’re saying was true, why isn’t everyone using a totally custom CMS? Why isn’t everyone building their own frameworks? Because ultimately to make a really good CMS is a hard problem to solve. The skill of a developer is only one variable.
The client doesn’t care how you built their site, only that it meets requirements. If the requirements are feeding multiple entry points, like website, mobile app, etc then maybe a decoupled system might work for you.
Contently and prismic are great resources. But in my experience, something decoupled is a bit more trouble than it’s worth for most content based websites I’ve done.
There must be some misunderstanding. Nobody wants to build a Custom CMS because it takes forever, and it’s deceptively complex. I don’t want to build a custom CMS (ever! lol) (Ironically, I have been building an LMS at my day job…which has taken over a year).
Realistically, you can forego using the customer facing view layer of any CMS, and essentially make it headless. That’s actually the approach I’ve taken a couple times, because I didn’t realize that there were actual headless CMS’s. With the rise of WordPress JSON API, it’s obvious that others are enjoying this pseudo headless approach WP can offer.
So, dev-time… Assuming it takes the same time to install/configure a full CMS and a Headless CMS, the only remaining difference is how long it takes to build your customer-facing site right?
A CMS isn’t going to help you there, because it isn’t a website builder (like say Squarespace). You are going to have to custom code that regardless.
Also, I’m not prescribing to use a Headless CMS because it’s better. It’s not a weapon to impress your customer that doesn’t know the different between JS and PHP (or care). Let the CMS handle the management side (content creation, authentication, asset management, etc). Then build your customer-facing app with the technology that you are fastest with and that you like to code with. It’s a tool to make things easier for the developer, IMO.
Love it! Some times it’s just the raw data that people need, so as Sir Tim Berners-Lee has also stated: Raw data, now! :-) http://www.wired.co.uk/news/archive/2012-11/09/raw-data
I think it makes a lot of sense if all CMS supported a API path as a part of their features. Why should all data be wrapped with HTML? The future could easily be based on digital assistants who would handle data sources for us. Just think about Siri and Cortana, no wrapped data/content there.
I wrote a blog post about this topic, which is in Danish, but you could use Google Translate to get it in English, should you be interested :-) https://www.linkedin.com/pulse/fremtidens-internet-er-api-baseret-sten-hougaard
/Sten
The elements of an insanely fast, highly available, low-maintenance site:
A cloud CMS to take care of high availability, load balancing across multiple regions, etc.
Angular 2 or another isomorphic JS framework
A simple static file server to serve your HTML templates, stylesheets, and scripts
Then just do all of the website logic client-side by interacting with the CMS’s API. View composition, user sessions, paging, searching, whatever.
Once the browser has downloaded your script files, it doesn’t need to make any more requests to your server. Okay, maybe a couple more requests to fetch some view files, but that’s it. In fact, by leveraging application caching, you could have the browser completely stop talking to your own server, even on future requests. It would only need to talk to the cloud CMS.
BTW, I mentioned using an isomorphic JS framework so that you can render the page server-side for crawlers. Maybe even for your visitors, but that’s not as big of a requirement.
I have using CMS Builder from interactivetools.com for several years now and would consider it headless. It is a fully customizable CMS code generator and database. They provide a mechanism to pull data from the database but no views. You create your own tables (they provide several common ones), use the code generator to get basic code to display the data and format as you wish.
They have a number of add-ons and a robust hook system to extend functionality. I am using a simple DB function to pull data, and twig to display it.
I have developed real estate sites, museum and art gallery sites, and even e-commerce sites. I can create a fully functional customizable site in a matter of a week or two.
ProcessWire (www.processwire.com) has been doing this for years. It’s API is ingenious.
Ditto. ProcessWire has more flexibility than any other CMS out there. It also has a very active community of users who love what they do and do it exceptionally well.
https://www.processwire.com/
Yes, ProcessWire is beautifully simple for editors yet reveals a powerful api underneath for both presentation and admin. I have not touched another CMS for 2 years now.
Awesome. Here’s another. https://cosmicjs.com/
Hey Kelley! I’m the creator of Cosmic JS. Thanks for sharing :) Let me know if you have any questions about Cosmic JS or need help getting started! I’d love to get your feedback.
If I’m not wrong, http://pitchfork.com is built on top of WordPress REST API and Backbone views. Pretty neat example of scalable architecture and good looks, without sacrificing performance, given the amount of traffic they handle.
All in gonna say is, Drupal 8. Completely headless from the start, every entity and view has an endpoint, and Dries wrote a really great post on bundling Drupal (inside core) with a framework like Angular or Ember.
They started calling this new concept of integrating more with a client side framework “progressive decoupling”. I highly recommend any of you to look it up and give it a read.
I’m doing this on my site. I run WordPress, and built a plugin to export my posts to static JSON files on the server (when saving/updating posts). Then, I built a Node/Express/Angular app that just grabs the correct JSON file (based on the URL slug) and throws the data into the view. I could have used the WordPress REST API, and that probably would have been more sophisticated, but I think it’s faster to just grab a single static file when changing pages. It could definitely be refined, but it’s been working great for me so far.
Adding another headless CMS service to the conversation:
http://getdirectus.com
Our take on a headless, API first CMS: http://getmesh.io
I totally agree that this is the new way of building the CMS. We are moving away from the antiquated installed CMS / Database model to a new service provider model (like everything else in the technology and non-tech space).
I’m the creator of the content platform Cosmic JS and it serves as not only an excellent platform for developers to build content for websites and apps freely and quickly, but also for non-tech savvy content editors to intuitively use. Cosmic JS is currently in private beta, but we have many apps and websites running in production. Sign up and try it out: https://cosmicjs.com. And once again, thanks for the great article Chris!
I’m a big proponent of this approach. For our new company website we were tasked with providing a user-friendly backend where anyone can add content (WordPress, ideally), but we also wanted the front-end to be a good example of our skills so we wanted to go all-out on it. I was really not looking forward to tinkering with spaghetti code in a WP theme, so we decided to turn WP into a headless CMS using the REST API plugin. So far it seems like a really good choice, I’m definitely doing this again in the future.
For me, it looks like, somebody rediscovered the RSS / Atom feeds and combined them with REST like URLs. And put a shiny JS framework on top of it, because it’s 2016 :)
But seriously, i think we are heading in the wrong direction. HTML with good semantic markup would be a better solution. Or how about a CMS / whatever system, that serves the same content in multiple formats based on the client requests Accept header field? Like an API with HTTP, XML, JSON, etc. endpoints.
Yeah! Like a Headless CMS! ;)
Eh, somewhat. It sounds like you’re talking more like a rss.js type spec — we considered it for WordPress core, but it wound up getting yanked because it felt like too much of a compromising middle ground between a proper REST API and the existing RSS feeds.
https://core.trac.wordpress.org/ticket/25639
We’ve built a WordPress API-first CMS over at http://www.rooftopcms.com and have built a few sites in Rails with it already (see http://www.hightide.org.uk as an example). We’ve open sourced it if you want to use it yourself.
We built a headless Drupal site for https://twit.tv which includes a content API built on Drupal 7 and the RESTful module.
Read more:
https://fourkitchens.com/our-work/twit-tv/
http://fourkitchens.com/blog/article/twittv-launches-content-api-and-headless-drupal-site
A self hosted open source alternative: Cockpit – http://getcockpit.com