Choosing a CMS: Why Iterate used Sanity for Northern Playground
Centra Implementation Case
In this interview, we talked with Lars Barlindhaug – Solutions Engineer from Iterate, a Norwegian consultancy with a modern and original approach to technology and business. A great example of their work is Northern Playground, which you’ll learn more about in the interview.
Read on to find out:
What the advantage of a headless CMS is
Why Iterate decided to use Sanity as CMS for their Centra project
Why image support is one of the most important things in a CMS
How to do bleeding‑edge JAMstack e‑commerce projects
Why a non‑headless solution wasn’t an alternative for Iterate
What is your role at Iterate?
I have many roles at Iterate. However, for the latest project of building the ecommerce website for Northern Playground, I was a hands‑on tech lead for the team. We were three developers and one designer. I was responsible for tech decisions, while also being hands‑on with the coding.
What projects do you usually do at Iterate?
We do all types of projects. Northern Playground was actually our first e‑commerce project. We’d been doing mostly larger projects for several years, working in‑house with clients. As of lately, we’ve been taking on smaller projects too.
We’re also starting our own ventures and startups under the Iterate umbrella. I’m working on one of them, it’s called Woolit. It’s a marketplace for knitwear, where we have gathered thousands of Norwegian knitters. They knit in the convenience of their homes, for people who order sweaters through Woolit – producing high‑quality clothes, only on demand.
Image description: Front page of Northern Playground's e‑commerce experience
What we’re doing in Woolit is very similar to what Northern Playground does, which is making locally produced and environmentally friendly high‑quality clothing.
First of all, can you explain what a headless CMS is?
In a CMS, you don’t just want plain text, you want rich text – with colors, links, and a format that can be understood across different platforms.
A headless CMS doesn’t output HTML, it outputs JSON data, so you need a way to encode that text, decode it on your client – and then you build the HTML.
Why not just have a CMS that outputs HTML?
If you’re making a native web‑app, you don’t even use HTML, you use different building blocks, so it needs to be encoded differently. The encoding/decoding process needs to make sense for rich text.
Every building block inside Sanity, each piece of content can be referenced. For example, you can make a list of “Top 3 best products”, and then link those products inside Sanity.
You don’t want to output HTML everywhere, because you might have an in‑store display, or you might want to only fetch images for TV screens. Plus, there’s so much more than HTML now – it makes sense not to lock that into your CMS.
Also, you need to create that HTML somewhere, and the HTML can be different on mobile and desktop. If you exchanged HTML, the CMS would need to handle mobile and desktop differently and independently. It just wouldn’t make sense, you need to divide the responsibilities. The CMS shouldn’t need to know about which platforms you are using.
So in our scenario the CMS just handles the data. The presentation of the data is done in the custom frontend system that we build. If we want to add a mobile app or in‑store display, we can do that without making any changes to the CMS.
If you were to send HTML from Sanity instead, you’d probably have to do the work that you do on the frontend, in a theme in the CMS, but it would be the same work, you’d just move it to the CMS instead of controlling it in a separate place.
Why did you choose Sanity as the CMS for Northern Playground?
We made the decision to start building e‑commerce on a headless platform, like Centra. This means we also needed to find a headless CMS that fitted well with our custom frontend.
In a full stack CMS, like non‑headless Wordpress, you input text and get ready HTML. You can then edit how that HTML looks and edit the themes (so you kind of manage the frontend in addition to managing content).
With a headless CMS, like Sanity, you input text and get GraphQL or JSON data out of it. No HTML comes out of the headless CMS. There’s nothing about the content presentation, there’s no structure or SEO built into the content at all, you have to build it all yourself in the frontend. All you get is the data, so the end page needs to be built elsewhere.
In the case of Northern Playground we basically get a list of products with images and rich text from Sanity, as well as an ID so we can link it to the list of products in Centra. Then we have to figure out the site structure and SEO in our custom frontend.
We’ve used Sanity a lot before, so it’s something we were familiar with. It’s a Norwegian product, so we’ve been following it for a few years, and it was kind of the path of least resistance.
With Centra, we had a new technology for the ecommerce platform, so we chose Sanity again so that our team wouldn’t have to re‑learn too much stuff, because deadlines were tight.
What are the most important things that you look for in a CMS?
The most important thing I look for is the editing functionality for webmasters that will use our platform everyday. Editing needs to work, be bugless, easy to use, preferably both flexible and simple at the same time.
Another cool thing is Sanity’s great support for images, which are crucial in e‑commerce. You can upload images and do automatic resizing on the frontend, depending on whether it’s a mobile client or desktop client.
Also, in Sanity you can make hotspots in images for your frontend to automatically crop them. If you have a picture of a full‑size man, on a smaller screen you want to crop only the head. With Sanity, it’s as easy as choosing a hotspot on the head.
That is something you REALLY don’t want to make yourself, so it’s nice to have out of the box.
Apart from Centra and Sanity, what else is in your tech stack?
Image description: Simple example of generating a page with Gatsby.
We statically generate each and every page of our webshops, which makes for awesome SEO and speed. We generate those pages based on data from Centra and Sanity.
This way of building sites is becoming more and more popular, and it’s quite interesting how we’ve kinda gone full circle. We’ve gone from multiple static pages (built a bit differently than today), then the industry went into single‑page apps that are refreshed all the time, and now we’re going back to multiple static pages again.
I think the static approach makes a lot of sense. Single‑page apps are heavy, especially for phones. This hurts your SEO, and SEO is very important for e‑commerce.
What would make you consider using another CMS than Sanity?
If I find something that works a lot better than Sanity, I wouldn’t have a problem switching it in all of my projects.
The CMS is very general when compared to other building blocks in a web project. If it works in one project, it’s safe to assume it’ll work for all my other projects.
Does Sanity require a lot of upkeep?
You have to maintain and update it. With Sanity, you deploy it to their service. It’s pretty straightforward. Even if you forget about it and let it be, it should still be ok – at least for a certain amount of time.
Sanity itself doesn’t have any user‑facing interface, it just fetches the data. So it’s less critical than, for example, full‑stack Wordpress, especially in places where the website handle credit cards, logins and such.
IMG description: Sanity is one of the most popular headless content management systems for structured content. Check out the official “Getting Started with Sanity” video.
ALT tag: Code editor next to visual editor from the headless content management system Sanity.
Would you recommend others to use Sanity for their Centra projects? Why?
Yes. For similar reasons that we would recommend Centra – most importantly it has a meaningful API. You write queries kind of like when you write against a database, but you do it against Sanity, and you get exactly the data you need out of it.
They also support GraphQL, which is really helpful for us, because we use Gatsby, which relies on GraphQL for getting data into our statically generated sites.
Would you ever have considered building Northern Playground with a monolithic all‑in‑one solution?
Short answer: No.
With a Shopify solution, anyone can do it, you can make a shop in one evening. Which makes sense in a lot of cases. Especially if you have a few products, and want to sell them locally.
In Northern Playground, on the other hand, there were several out‑of‑the‑ordinary things. For example all products have a male or female fit on each product (a bit different than typical webshops, as you don’t choose the male/female section. Instead you can select the right fit on every product individually).
Also, the Northern Playground team wants to build on that page, create a community, as well as create crowdfunding campaigns for new products. With the tech stack that we chose, there are lots of different things you can do with the website that go beyond selling products.
We couldn’t do that with Shopify as there simply isn’t enough freedom and flexibility. Then again, if you came to us and said “I have these 3 products and want to sell them online”, I’d advise you to set‑up a Shopify account. It’s all you need, and you’ll save a lot of money compared to building a custom system for your e‑commerce before your product/brand has matured.
There’s also Wordpress and Woocommerce. With these systems, you can do a lot yourself, you get a lot out of the box, but you also have plenty of ways to customize them. Clients that come to us are often in the process of moving away from these systems. As they continue to customize, the quality of their website goes down, pages become slow, error‑prone, and once again – things go down. That’s what you get when you customize these systems too much. It becomes a big monster that nobody can control.
Lots of people are experts at Wordpress, and they can help you, but if you do too much and you’re not an expert yourself ‑ you’ll find yourself in a bad place.