Background
When I started out working as a developer consultant, one of my first projects involved Episerver, back then, I didn’t know much else and just went with it. After working with Episerver for a while, I got assigned new projects and eventually tried other Content Management Systems like Umbraco and Contentful. With a broader view and a more extensive technical knowledge, Episerver now seemed a bit old and bulky.
When I lately was up for another Episerver gig, I wasn’t too excited at first. All I could remember was a lot of Razor views and jQuery hacks to be able to pull off and implement the design and user flow the designers had presented to the customers.
I started looking around a bit and noticed that Episerver now offers a Content Delivery API. This API was great news, and it means we are now able to work with Episerver as a headless CMS without custom hacks almost out of the box, which gives us a lot of new possibilities. But first things first:
Non-headless vs headless
A traditional CMS (non-headless) is responsible and controls how the content within the CMS is presented. The “head” can simply be seen as the process of generating the HTML that is viewed in the browser. With Episerver, this means Razor, often using an MVC pattern.
Headless, on the other hand, don’t care about the views, only the data. It’s more or less a content database that let us fetch this information using it’s APIs. Headless is excellent in terms of flexibility, and we can use whatever technology we want to consume and present the content. Another advantage is that we can make use of a single source of content for display on multiple devices and across multiple channels. It’s up for each consumer to create the “head” and present it to the user.
What does this mean for me working with Episerver?
Shortly put, Episerver as headless handles the content structure and still gives us a backoffice the editors can use. Presenting this content is, however, 100% up to me as a developer to decide upon, if the use case advocates it. A hybrid approach would also be possible, for example, use Episerver as a non-headless CMS for the web, but consume the instance as headless for a native application for my smartphone. The possibilities are many!
I decided to create a proof of concept with Episerver and the API and rather quickly got a site up and running using Vuejs as my “head”, still with OPE (On Page Editing) and preview functionality for the editors. Great! If I want to make use of SSR (Server Side Rendering) or SSG (Static Site Generation) with Episerver, this should be possible as well (I haven’t made any proof of concept regarding OPE and preview here though).
The release of the content delivery API is, in my opinion, a move in the correct direction for Episerver, now I’m in control, and that makes working with Episerver a whole lot more interesting.