What to Really Look Forward to
You will like the headless approach. As you are introducing Episerver Delivery Core, it will enable a content-model-first design approach, helping you establish parallel work-streams of experience design, content creation and platform development. Opposed to platforms like Contentful which also enable a content-model first design approach, with Delivery Core, Episerver removes the complexity in the technical connection between content, experience (visual, interactive, functional) and the domain/logical layers of your application.
Continued On-Page Editing Experience
Your editors will love the continued on-page editing experience, which most other decoupled or headless CMS' severely lack (without added efforts or dedicated preview environments). Because of the way Episerver continues to give you an SDK for the implementation of the experience layer (via .NET 5 and Razor), we expect the on-page editing to activate out of the box.
Dependent on how you're running/operating your Episerver platform today, the Episerver Content Cloud offering is designed to remove the infrastructure complexities and logistics this type change requires. If you think about it, Episerver Delivery Core will introduce a dedicated web-app (logical infrastructure component), with the responsibility of delivering an interactive, end-user facing web experience. It relies on a fast and secure connection to an underlying Episerver Content Delivery API (headless component) to satisfy the content and logical needs (personalization, a/b tests etc.) your new experience requires.
Ease of Upgrade
We expect this approach to ease the upgrade of your Episerver CMS/platform further. If you consider below reasons, the introduction of Episerver Delivery Core softens the dependency between between your end-user facing experience and your underlying platform:
- The content delivery APIs (headless component) rely on semantic versioning to control the impact of platform change, hence negative effects introduced by platform change will be more predictable compared to today. At the end of the day, Content Delivery APIs will be the glue between your experience and your platform implementation going forward.
- Content delivery and management are logically separated, meaning you can deploy minor-upgrade packages to the two independently.
- Episerver Delivery Core will most likely rely on a light and very strict version of the platform’s underlying framework, which means the majority (if not all) of the change associated with an upgrade targets the management side of your application. It means your experience stays untouched for the most part.
What to Have in Mind
Migrate Your Existing End-User-Facing Web Experience
Your existing end-user-facing web experience must be migrated to adopt the new Delivery Core approach, which includes planning for changes such as:
- Migration of your Razor views to adopt the change to helpers introduced by .NET 5 (Core).
- Introduction of .NET 5 (Core) compatible dependencies, to replace existing .NET Framework optimized packages.
- Lessen your dependency between Episerver and your new Content Delivery component through the more light-weight packages.
- Depending on how tightly coupled your existing Episerver solution is, Delivery Core requires a clear separation between the layers of experience (visual, interactive, functional via MVC and client-side code), content (content models via page types and block types) and domain/logic. It may require you to re-factor certain aspects of your solution.
Customization Might Be Required
E-commerce transactional elements, like a simple add to cart, are not supported by Content Delivery API, meaning the headless nature of e-commerce, required to adopt Delivery Core in an Episerver Commerce-heavy project may require customization and/or adaptation on your end at first.
Additional Web-App Might Be Needed
If you are running Episerver on a self-hosted cloud, you would need an additional web-app for the dedicated delivery application, hence you should expect to change your logical setup.
What to Monitor and Validate More Carefully
With a headless approach, an increase in the amount of networking traffic required to serve up your experience should be expected. Instead of a database connection (and cache) being used to retrieve content, we will now see an added layer of HTTP traffic to power Delivery Core as well. It is of course something Episerver will ensure is being managed properly (performance, content cloud subscription etc.), but if you are self-hosting, it may increase your average data usage, hence bring up your operational costs. It ultimately depends on how you run your solution today!
At the end of all this, it is important for me to state how exciting this additional delivery option is. It is not something you're forced to adopt—so instead of you looking at it through the lens of concern or need for technical change, you should see it as an opportunity for gradual adoption of new technology, when you and your Episerver solution are ready for it.