The Headless CMS architecture is red hot in the JamStack community right now. I feel like new products and services are popping up daily. I had the pleasure of sitting down with Lucie Haberer, DevRel at Prismic, and Samuel Snopko, DevRel at Storyblok to get the details on this emerging product category, its origin story, features, tradeoffs, user experience, futures, and more.
Below is a summary of the information that I learned from our conversation.
The Pain of Getting Data out of the CMS
The growing use and improvement of frontend tools and frameworks puts increased pressure on existing monolithic content management systems to make the data more accessible outside of itself.
Getting content in a monolith, like WordPress, was relatively quick and easy.
Getting that data from there to anywhere else that wasn't a hosted webpage, within that single-engine, was far more difficult. Coupled with the skyrocketing use of mobile devices, apps, and increased web access around the world, the monolith became a point of frustration for developers, and a bottleneck for businesses needing to update and adapt quickly.
Who's Leading Who?
Is the JAMStack empowering Headless CMS, or is it the other way around?
From static site generators like Jekyll, to full-blown web applications backed with content available via APIs from Headless CMS, this relationship isn't one-sided, but rather reciprocal.
As UIs needed more options and flexibility over the content, the APIs that Headless companies like Prismic and Storyblok offer were built-out to meet these needs. As the ecosystem of content APIs expanded, so did the features offered by visual studios, as well as their use in web apps, mobile, video, and smart devices. It is this mutual benefit that has led to explosive growth in both Headless CMS and JAMStack use across the industry.
Not just creating content, but changing content shape
I think the real superpower of Headless CMS lies in its ability to let anyone not just create content, but modify the shape of the content itself.
Imagine the scenario where a company wants a quick landing page for an upcoming event. Now, most of us would roll our eyes at the use of "quick', but bear with me.
It's a "simple" page with a hero image, some event details, an image, and a video. It's a specific use case, and they don't want to add it as a blog post along with the other content. Maybe they want it at '/coming-soon' on the domain.
Well, that URL route doesn't even exist currently. Could this be done without ever contacting the development team?
Since the content is decoupled, and just pulled via APIs when the site is built, surely you'd need some tweaking in the code for the HTTP fetch calls? With Headless CMS, nobody from the development, ops, or admin teams needs to be involved.
The setup would be something like this: There is a defined set of routes within the content. A route has a slug property and Page property.
Page is another data type. A page is an array of basic types like image, text, date, and yes even video. So in our scenario, the team- without you, the developer- can go in add their route, name whatever they'd like, and start building out their custom page.
Arranging the image on top, with the right copy, and the video above the fold is a matter of simply ordering the item in the content interface. Once it's all set, they can retrieve a preview link, send it to the director to view and approve, and then hit publish. Whenever content is added or updated, our site fetches the data, executes npm run build, and then pushes that build-out across a network of CDNs.
In this case, our fetch routes function has been happily iterating over a list of type routes on every build- this time it just so happens to have a '/coming-soon' element to it. So it creates the actual route, and then fetches the Page data from the CMS. It is then formatted, and styled as just as data from a Page type would be. Then it is bundled, and deployed with the rest of the site. Voilà.
Now, it goes without saying that a lot of time and consideration goes into setting this all up, testing it, and getting it to work together. But, it illustrates the level to which we can empower others to create and build on this model of decoupling content, provided by Headless CMS.
Just The Beginning
It is clear that the paradigm has shifted to Headless content, and that consumption is an aggregate of many sources into multiple formats. From mobile apps, web, to voice assistants, and curbside pickup, people everywhere are adapting and changing their habits. As developers, we have the tools to build an awesome and empowering experience for others to create their vision on top of this. I am excited to see the next idea, product, or format that is published without direct help from the developers.
