My Immediate Reaction
Everything has been categorized to help you digest, regardless of you being here to satisfy your curiosity, help the planning of your digital roadmap or simply because you are validating Episerver as the platform to support your next wave of digital capability.
'What to really look forward too' captures high-level things that I am personally really excited about, helping Episerver differentiate or even make our digital solutions stand-out more. On the other hand, 'What to have in mind' and 'What to monitor and validate more carefully' are cherry-picked thoughts that requires your attention, at varying level of severity.
What to really look forward too
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 other CMS' enabling a content-model first design approach, like Contentful, Episerver with Delivery Core 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 lacks (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 abstract away 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 makes the line of dependency dotted between your end-user facing experience and your underlying platform
- The content delivery APIs (headless component) relies 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 API 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/dependent on a light and very strict version of the platforms 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 of 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.
- Dependent 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
ECommerce transactional elements, like a simple add to cart, is not supported by Content Delivery API, meaning the headless nature of ecommerce, 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 change to 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 graduate adoption of new technology, when you and your Episerver solution is ready for it.