My experience with Wisp.blog - Part 6

This is the conclusion of my experience implementing Wisp as a blog. Since the last time I've added Storyblok as a CMS next to Wisp, so I'll shortly describe my opinions on that before concluding with my thoughts on Wisp as a blogging platform.

Implementing Storyblok

First, I already have a lot of experience building Storyblok based websites, so I won't have any new insights on that. I'll focus on developing a Storyblok/Wisp hybrid application. One thing that became clear early on was the importance of structure in your NextJS application. I made the choice of having Storyblok and Wisp as separate Route Groups. This ensured that I'd have no conflicts between them, the downside is that I lost the ability to add CMS content to my blog overview and blog article pages. And the second thing I decided was to have the 'blog' prefix be hardcoded in my routing for the blog, this gave me the following filetree:

- src
  - app
    - (storyblok)
      - [...slug]
        - page.tsx
    - (wisp)
      -  blog
         - page.tsx
         - [slug]
           - page.tsx

Of course, if that every becomes something I'd like to do, I could add a bit of logic to the (wisp) pages to load Storyblok content in there. This way I could at least keep my blog specific logic separated from other content. If I'd ever decided Wisp won't fit my requirements anymore, this folder is the only one I'd have to change.

Cross dependencies in a Monorepo

I've mentioned that I'm using a Monorepo for this project, with a strict validation on dependecies so features can't be dependant on other features to prevent cross dependecies. This is where I encountered a foreseen issue while joining Wisp and Storyblok. I made separate packages for the Storyblok and the Wisp integrations, and on my Homepage I wanted an overview of the latests blog posts. Since the homepage is structured in Storyblok I needed a way to have a Wisp dependant Blok in my Storyblok package.

Eventually I solved this by introducing adapters into my NextJS application. This is a new folder outside of the app directory where I can write code to join two (or more if I ever need to) packages to use in my app. My Storyblok adapter ended up looking like this:

// The Bloks defined in my Storyblok packages, things like layouts, texts, images
import { Bloks } from '@features/storyblok';
// The Bloks which are dependant on Wisp
import { bloks as wispBloks } from '@features/wisp';
import { apiPlugin, storyblokInit } from '@storyblok/react/rsc';

// Joining the two lists of bloks together.
export const components = {
    ...Bloks,
    ...wispBloks
};

export const getStoryblokApi = storyblokInit({
    accessToken: process.env
        .NEXT_PUBLIC_STORYBLOK_CONTENT_API_ACCESS_TOKEN as string,
    use: [apiPlugin],
    apiOptions: {
        region: 'eu'
    },
    components
});

After solving that, everything else went without a hitch.

My thoughts on Wisp.blog

My experience building a blog with Wisp is quite a positive one. The documentation and SDK are really clear and straightforward, and there were no weird undocumented things or surprises. Even the 'advanced features' weren't complicated. And as a user of the Wisp interface, I don't really have complaints besided the lack of an in-app preview. Everything has a very 'simplicity is king' approach and you'll never have to search for anything in the dashboard. Some settings are a bit hidden, but you'd only have to set those once.

I set out on this adventure with the goal of discovering if a Wisp blog implemented in Storyblok would be preferable over a blog build in Storyblok, and the answer to that is more nuanced. The major strength of this approach is Wisp's simplicity, it's purely a blogging platform with everything you need to do that, while Storyblok is a CMS first. I didn't have to define a 'blog' content type or build logic to fetch and paginate between blog entries on an overview page. Comments were also something that worked out of the box, while in Storyblok this would have to be custom built. Some of the other features Wisp offers, like related posts, I haven't had the chance yet to try out, since I don't have enough content to really judge this.

The best blogging implementation I've done in Storyblok also required the usage of Algolia as a search engine, both for filtering on tags and having a proper text seach, things which are native to Wisp.

But the judgement on "should I use Wisp as a blog inside my Storyblok application" is a definitive "It depends".

Some reasons why you might want to add Wisp

• A quick time to market

• You only need a 'simple' text editor, no custom layout components

• Different access for content editors and blog writers

• You might want to switch CMS and don't want to move your blog as well

Some reasons why you might not want to add Wisp

• No integration between Storyblok and Wisp

• All your content stays within a single source

• You want more than just text editing

Conclusion

Implementing Wisp isn't complicated, and it certainly is possible to have a site powered by both Wisp and Storyblok. But using them together is a decision you have to make. I think it's really dependant on the project you're working on and the requirements of it. Do you want something quick and simple? Then Wisp is a great choice. Do you have specific needs, or want to keep everything under a single roof? It's not a bad choice to build the blog in your CMS of choice.

Overal, both are valid decisions and neither is inherently wrong. What you gain in simplicity of implementation, you loose in overal complexity of your application when choosing for Wisp. The most important factor is probably the time you have. Wisp is quicker to setup but Storyblok can be configured specifically to your needs.

Powered by wisp