Storyblok: The Benefits of Going Headless
We’ve recently begun integrating Storyblok as a new CMS into the Spryker platform of one of our longtime client projects. Here’s a brief look at Storyblok, what we’re building with it and why — plus some details on how we’re making it work.
Before we get into the weeds, let’s take a look at Storyblok itself. On its website, Storyblok touts itself as the world’s “first headless CMS that works for both developers and business users”, i.e. people who manage content. That’s lofty marketing speak, but there is some truth to it, mainly for two reasons. First, Storyblok offers a visual editor that allows content editors to see what the changes they are making will look like live and in color, as well as content blocks that can be customized to their everyday needs.
For developers, Storyblok’s headless architecture is extremely persuasive. In simple terms, “headless” means it is completely independent of the front-end. It does not care about where the content created with it gets displayed; it only stores content and delivers it wherever needed, be it a website, a mobile app or an e-commerce platform. Managers add content via the Storyblok app and then the CMS delivers that content as JSON via a RESTful API.
Moreover, since it is headless, the Storyblok CMS doesn’t have to be the same coding environment as the rest of the system landscape. No matter if you are using php, javascript or java for your backend, it can be easily integrated. Now, Storyblok is very far from the first to do this. Headless is clearly the way the web is going (to be fair, over a third of the web is running on Wordpress, so we’ve still got miles to go). But Storyblok does what it does really well — mostly by combining a straightforward developing environment for developers and ease of use for content editors.
What you see is actually what you get
When we as web developers hear WYSIWYG, we think back to the old days of Dreamweaver and the like. For content editors with no developing experience, it’s actually really useful. While Storyblok’s look and feel is not much different from other CMS out there, the visual editor is its coolest feature, hands down. Editors can see what they are changing live on the site while they are dragging things around and typing. Hit save, publish, and boom — there it is.
In a way, the idea is to actually make us developers obsolete — at least in the day-to-day of editing content on a website. Gone are the days of constant Slack messages to change font sizes, move stuff around or switch out images. As developers, we can lay the groundwork for content editors to do their work — and then we are free to worry about building other things.
What we are building with Storyblok
Enough with the backstory. We have begun implementing Storyblok in one of our longest running client projects. As many of our clients, the company runs a Spryker commerce platform that we built, this one consisting of two brand stores with various localizations. Until now, their team has been using Spryker’s built-in CMS to manage their content. If you are a Spryker user, you know that the CMS is not quite its biggest selling point, at least not for content editors — mainly, there is no live preview and you have to wait for changes.
Now, as a manufacturing business also in wholesale and d2c retail, our client is continuously updating content and has very specific requirements. The beauty of Spryker is that it is modular, so with some reasonable effort, we can actually switch out the CMS and integrate a solution more suited to our client’s needs.
Putting Storyblok to use
We began with an investigation period, where we put Storyblok to the test to see what we could do with it as developers, as well as what the content team on the client side could do. We built a structure for editors to be able to do whatever they wanted and created specific guidelines for creating content for a certain page. The structure has to be easy enough to navigate and at the same time expandable. Also it has to work under the commerce platform’s specific conditions:
- 2 brands at the same time but with same set of components
- 5 different country-shops for each brand
- 3 different translations for each country-shop
When we presented our first iteration and showed the client what “the future” will be like, they had clear pointers and ideas to adapt Storyblok to their needs. Storyblok’s customizability and modular approach really came in handy in removing and replacing things.
For us, gradually integrating Storyblok into the platform piece by piece was the way to go. Step by step, we are switching out only a handful of content blocks at a time, such as a hero image on the home page and some text to go with it, and adding placeholders for content coming from other places.
The Scenario
Let’s dive into a single scenario to show Storyblok in action. Our homepage consists of 10 different contents coming from the old CMS and some dynamic content. We want to add a text block below the hero image on the homepage without touching the rest.
The Code
The first step is to create a new story on the Storyblok app. We call this the home-page story and we will add some content to it. Other than the text content in this story, we have to create a placeholder for the rest of the content on the homepage. We call this component non-storyblok-placeholder. The non-storyblok-placeholder has only one field that stores the name of the placeholder. We will use this name later in the Vue.js code to identify each slot. After creating the content and the components in the Storyblok app, the resulting JSON looks something like this:
Now we need a component to fetch this JSON and render the components in our e-commerce app.
ContentLoader.vue is a very basic sample to render the content fetched from storyblok’s api. Our shop’s frontend layer is a mixture of Symfony and Vue.js. Now we want to use the ContentLoader.vue in our frontend.
Doing the above means that the content coming from Storyblok will always get rendered above the content of the page (line 10), which is good in some cases but we want more flexibility. To fix this problem we will pass the whole main as slots into the ContentLoader.vue. Here is how we are going to change them:
We pass the Hero section of the homepage as a named-slot (hero) and the rest of the homepage as the default slot. The slot name must be the same as the placeholder’s name. We also modify the ContentLoader.vue so it passes the slots to the child components too. Now we need to create the child components.
Components in the HomePage.vue will be checked if they are a non-storyblok-placeholder or not. If they are, the corresponding named-slot will get rendered. If not, the corresponding component (in this case the TextBlock.vue) will get rendered.
By doing the above, we empower the content editor to create and move the newly created text-block around the content not provided by Storyblok.
What about the assets?
Storyblok also allows us to build and integrate custom components. For example, the client has lots of different kinds of image and video assets, and uses their own AWS S3 bucket to manage it. We found Storyblok’s asset manager lacking — so we removed it and simply built our own custom plugin. Now, the content editor doesn’t have to worry about where its assets are being uploaded or even resizing them. Storyblok just does so on the fly in the browser and then uploads to the clients own bucket.
Getting started is easy
Finally, there is hardly any learning curve for developers starting out with Storyblok — at least if you are a seasoned Vue developer. The front-end is built with Vue.js and plugins can be developed using Vue as well. Goes without saying: if you know any other javascript front-end library, it should be just as easy.
Plus, we really liked the fact that you can just sign up for a free plan and start building with it. After we started developing, two of our colleagues began implementing Storyblok for their own personal projects — both back-end developers with no relationship to Javascript. That should be enough of an endorsement in any case. Let’s see what we can build with it!
