Storyblok Implementation

DEVS x DEVS <Storyblok>

Drupal vs. Storyblok: What are the fundamental differences? And can a new CMS truly simplify development? Calvin Barrett, Strategic Partnership Manager, interviews developer Colby Chiste to get the inside scoop on Acro Commerce's recent Storyblok project, revealing the platform's strengths and why it made their workflow seamless.

Video Transcript

Calvin: Thank you, Colby, for taking the time today to chat about our Storyblok implementation for a recent project. Today, we're going to run through a couple of questions about your experience working with it and what you enjoyed about the process during our implementation.

I'll start by asking for a synopsis of what you were tasked with as part of the project.

Colby: Sounds great! We were tasked with using Acro’s Gesso Accelerator to quickly spin up a decoupled blogging website, utilizing Storyblok as the backend content management system and Next.js for the front end. We had about a month to do it, and that’s exactly what we did. It went really well and was a smooth process overall.

Calvin: Can you tell me — since we've worked extensively with Drupal in the past—what some of the key differences were when switching from Drupal to Storyblok? What did you find refreshing about the experience?

Colby: Yeah, absolutely. At a high level, they're very different in terms of architecture. Drupal is a much more monolithic system, whereas Storyblok is entirely geared toward a headless infrastructure. In fact, it’s built specifically for headless implementation. Storyblok does not provide a front-end solution out of the box, so everything on that side is created separately. However, it provides everything needed for a headless CMS, including an intuitive admin interface for content editors, marketers, and developers, as well as REST and GraphQL APIs.

In Drupal, front-end development relies on Twig templates and HTML/CSS integrations by default. While Drupal does offer a decoupled experience, it requires additional modules and configuration. Because Drupal is open-source, it has a steeper learning curve and is more complex to use. In contrast, Storyblok is proprietary, meaning you can’t modify its internal workings, but this makes it much more streamlined and user-friendly.

Both platforms have plugin ecosystems. Storyblok’s apps are still maturing and offer a smaller selection than Drupal’s module system. However, Storyblok allows for the development of custom apps, which are vetted before being added to the marketplace. In contrast, Drupal’s open-source module system is rich but requires developers to carefully vet the quality of individual modules.

Calvin: Awesome. I wanted to touch on two things you mentioned. First, Storyblok is headless, meaning it focuses on the backend experience while allowing full customization of the front end. With that in mind, did you find the interface user-friendly and intuitive as you built it out? Given that Drupal can sometimes be confusing, how did Storyblok compare in terms of usability?

Colby: Yeah, even without comparing it to Drupal, Storyblok is very approachable and intuitive. I didn’t need to read a ton of documentation to understand its features and limitations. The interface was straightforward, and building pages and working with components was simple.

Calvin: Was the API easy to work with? Did you run into any hiccups or challenges? I know that using a monolithic system and trying to decouple it adds complexity, whereas a headless-first system is designed to simplify development.

Colby: Yeah, absolutely. Storyblok provides first-class tooling to work with its API, including built-in parsers for things like rich text. That meant we didn’t have to do much manual parsing or worry about data formatting in our front-end application. It was seamless.

Calvin: I know we initially created a website for this event, and migrating sites can be challenging. While this was a smaller-scale project without much pre-existing content, what do you think is most important when migrating from another system, like Drupal or a different platform, to Storyblok?

Colby: It depends on the system you're migrating from and its functionality, but at a high level, you need to consider a few key factors:

• Schema Replication: Your Storyblok space must be updated with blocks and fields that match the tables and columns of your source system.
• Source Cleanup: Migration is a great time to remove unnecessary data and clean up the schema.
• Business Logic: If your previous CMS included business logic, you need to move it to middleware, microservices, or another abstraction layer, as Storyblok is purely content-focused.

Calvin: That makes sense. Now, going into this project, you had never worked with Storyblok before. Were there any concerns or preconceived notions you had about tackling a completely new system? And did those concerns hold up throughout the project?

Colby: Yeah, the biggest concern was data fetching—what kind of data to expect and how hard it would be to configure the backend. Coming from a monolithic system like Drupal, I was also worried about onboarding time. But once I got in there, I found the interface to be extremely intuitive, especially compared to traditional CMS platforms like WordPress or Drupal. It was a refreshing change of pace—much more streamlined, with only the tools you need and none of the excess complexity.

Calvin: What was your favourite feature? Whether it was the visual editor, GraphQL handling, or error messaging, was there something that stood out?

Colby: I’d say the visual editor. When working in a coupled architecture, you don’t have to think about that, but in a headless setup, it becomes essential. Storyblok’s visual editor was well-designed and easy to configure, making content editing much more user-friendly.

Calvin: Once the project was complete, how did you communicate what you built to the marketing team? Did Storyblok’s design make it easier for them to get up to speed without much training?

Colby: Yeah, a great point to bring up. Initially, there was some confusion, particularly in the visual editor, about how to navigate the component tree. But we quickly found that Storyblok provides tools to simplify that experience. We added custom field labels, set up data previews, and included descriptions, which made it much easier for marketing to understand how to use the system. Once those adjustments were made, they needed minimal onboarding—just a quick demo, and they were off and running.

Calvin: That’s great to hear. So, based on this conversation, it sounds like Storyblok’s biggest strengths are ease of use, quick development time, and reduced complexity—not just for developers but also for training other team members. It allows you to get to an MVP state faster while still enabling customization.

Would you say that sums it up?

Colby: Yeah, absolutely!

Want to know more about Storyblok?

Send us a message below for a free custom demo, and see how a powerful CMS can change your business!