decoupled & headless content management with episerver · 2017-05-11 · headless cms is often...

Decoupled & Headless Content Management with Episerver byDeaneBarkerChiefStrategyOfficerBlendInteractive

Episerver 542 Amherst Street Nashua NH 03063 USA

+1 603 594 0249 www.episerver.com

2 /9

Introduction: The End of the Silo

Content management is de-siloing.

That’s an awkward word, and there doesn’t seem to be a graceful alternative. Nevertheless, it’s accurate: CMS has traditionally been a silo, and that silo is steadily unraveling.

The days of the monolithic, delivery-side CMS, from which all of an organization’s content is disseminated, are coming to an end. A single point of storage is clearly ideal, but the methods by which content gets out of that repository and is actually delivered to the content consumer – the “channels” – are quickly expanding.

What used to be simple delivery paradigm – visit our website, full stop – is fracturing into dozens of potential channels. Content now fans out from a (hopefully) central location to a sometimes-confusing array of channels, formats, and delivery architectures.

With this comes a mushrooming of delivery technologies. Your web developers are working in one language, your mobile developers in another, and your social media team in a third. Different channels bring with them entirely different skillsets to get content from Point A to Point B.

The one constant in this maelstrom is the content itself. It still needs to be created, managed, previewed, approved, and optimized, regardless of delivery method. It’s standing by to serve the organization, independent of output technology. To accomplish this, content needs to be treated as a service that supports your channels and your delivery teams.

At this moment, we could drift sideways into an abstract discussion of “service oriented architecture” and “microservices,” but let’s narrow our questions to the practical:

• How can we use Episerver to manage content and deliver it to multiple channels and technologies, in addition to our website?

• What benefits does Episerver bring to this scenario, in comparison to a dedicated headless CMS?

These are the questions we’ll be unpacking and answering in the following sections.

Delivery Architectures and the Blurry Lines Between Them

First, a few definitions around delivery architectures, just so we’re speaking the same language. • Coupled. This is the most common architecture for web content delivery. A coupled CMS retrieves content

from the repository, formats it, and delivers it real-time from the same system that the content consumer accesses. Content management and delivery are two sides of the same system; editors manage content in the same system from which the content is delivered. The benefit is that the real-time aspect of delivery allows customization to the context of the consumer.

• Decoupled. In this architecture, a content repository manipulates and formats content into an artifact of some kind (often a static HTML file), then moves that artifact to a separate delivery environment. The consumer accesses that delivery environment, and might never come into contact with the repository directly. Some years ago, this was a common model of delivery and has benefits in scalability, fault tolerance, and (sometimes) cost. However, it gradually lost ground as the immediacy of coupled architectures became more valuable.

• Headless. In this architecture, the delivery environment is separate (as with decoupled), but that environment contacts the repository in real-time to retrieve content. The delivery environment might be a website, a mobile app, or a background process, all using the content repository like a central database. The term comes from the idea of delivery being the “head” on top of the management stack. Remove that head, and you have a “headless” CMS.

There are competing definitions for the above terms, but these are the most commonly held. And know that the lines between them are blurry. For instance, many coupled systems will cache content in a content delivery network (CDN),



3 /9

which is a form of decoupling. Additionally, many coupled systems deliver client-side code which makes Ajax calls back to the repository, which is a form of headless.

Episerver has traditionally been a coupled CMS. However, as we’ll spend the rest of this paper discussing, it has enough extended functionality to be perhaps a more competent headless or even decoupled CMS than some systems that are “native” to those architectures.

Key Point There are three major architectures of content delivery: coupled, decoupled, and headless. The lines between them are sometimes blurry, and an implementation will often employ more than one architecture.

Headless scenarios are often hybrid, rather than pure Before we get into technical specifics, we need to establish a point: many situations are not only headless but are, in fact, also headless. A very common scenario is an organization that needs a web presence but also wants to deliver content to other channels.

To Episerver, headless and API-driven capabilities are an extension of its core purpose: a website management and delivery platform. Episerver has solved that particular challenge and taken the extra step of surrounding those core capabilities with a competent API and enough integration points to use the system as a base from which to project your content into any number of different platforms.

Headless CMS is often positioned as the opposite of a traditional web CMS. Episerver rejects this dichotomy. Headless is in addition to what the Episerver platform normally does. One discipline is simply an extension of the other.

And here’s why this matters: because there’s a natural overlap between the two disciplines. Episerver didn’t need to build a new CMS from scratch – the core web CMS product is a natural, flexible base for an alternate delivery paradigm.

Episerver is headless when you need it to be, and a fully-featured coupled CMS when you don’t.

Key Point Episerver allows for both paradigms: traditional coupled website delivery, and headless/decoupled API delivery.

Editorial workflow is universal and crosses delivery architectures This is a bit of an over-simplification, but the “head” in “headless” refers to the delivery tier of the entire solution. A headless CMS is one that delivers content via an API instead of concerning itself with templating and management of the delivery environment.

This is a good and valuable thing. But when you step back and consider the entire content management environment from end to end, that’s a relatively small piece of it.

Headless content delivery doesn’t exist in a vacuum. Regardless of how it’s delivered, content still has to be, well…managed. Editors need to be able to create, collaborate, and control their content. There are infrastructural issues to consider, such as user and group security management, content aggregation and architecture, reporting and versioning, etc.

This interface and workflow is a UX and experience challenge in itself, and it’s something that Episerver has been solving for over a decade.

Even a pure headless system needs the basic functionality that allows editors to create and manage content – call these “table stakes” features. These are patterns that Episerver has been solving and perfecting for years. The API capabilities simply leverage these features into a new delivery layer, without wasted effort reinventing those wheels.

Unlike other vendors, Episerver never had to start from scratch to meet the new headless demands of the marketplace. Headless architectures merely added a new dimension to the base of editorial and content functionality that has been continually refined over the last decade.



4 /9

Key Point Content, no matter how it’s delivered, depends on editorial and administrative functionality. This is a complicated experience problem that Episerver has been solving and refining ever since its inception.

Episerver allows in-context preview based on multiple contextual factors One of the great challenges of multi-channel content delivery has been in-context preview. Mark Boulton summed it up best when he said this:

The problem is this: The question content people ask when finishing adding content to a CMS is ‘how does this look?’. And this is not a question a CMS can answer anymore – even with a preview. How we use the web today has meant that the answer to that questions is, ‘in what?’.

The final presentation of content is necessarily affected by the container in which it renders. Between adaptive and responsive design, visual styles and layout can swing wildly between different resolutions, devices, and mediums. Previewing content on a web page is not helpful when you’re trying to see how it will look on your mobile app.

A content editor faced with creating and editing content might need to review that content in a dozen different platforms, resolutions, and personalization groups in order to ensure it works across all platforms and audiences.

Episerver supports multi-channel preview along multiple axes:

• Device

• Language

• Personalization group

Note that “Device” is left entirely up to interpretation. While "iPhone Vertical" is fairly obvious, there’s nothing stopping you from implementing “Billboard on I-90” either. With this, editors can view their content on an in-store advertising display, in Spanish, as it might look next Tuesday at 3:00 p.m. for stores in Alabama.

Editors can go even one step further and edit content directly in these channel-specific previews. If your content is destined for display in your Android app, an editor can start there and work backward to other platforms.

Key Point Episerver understands that content presentation is a potentially endless combination of factors. Editors have the freedom to specify these factors and get an accurate view of how they might affect the presentation of content.

Episerver allows rich, expressive content modeling To date, headless CMS implementations have followed a relational database model. Content objects have been roughly analogous to records in a database table, with strongly-typed fields, but little relationship between records.

This model can be simplistic and constraining. With no overall content architecture where all content fits into a unified whole, it can be difficult to form aggregate structures like taxonomies and site navigation.

Episerver brings with it years of content modeling experience, enabling richer content modeling that more accurately reflects the logical domain of content.



5 /9

Episerver deals in three core types of content: pages, blocks, and media. Pages are organized into a tree and have a URL segment. Blocks are free-floating content elements, available for embedding into other content as necessary. Media are file-based assets, used in support of other content.

• Episerver pages are traditionally URL-addressable, but this is entirely optional. To call something a “page” just means a URL is available for it, if desired. If Episerver is being accessed headlessly, this can be simply ignored.

• All content is strongly-typed, with a palette of over a dozen property types, which are fully extensible, using custom interface elements and generating custom, strongly-typed data structures – if your desired property is complex, it can return an object instance of a class of your own design. Even file-based content has a strongly-typed object associated with it that can store arbitrary metadata.

• Properties can have enforced references to other content objects, limited by type if desired. A drag-and-drop interface allows editors quick access to compose complex content consisting of on-the-fly aggregations of multiple objects.

• Blocks can be global (to be used anywhere), or associated with other content. A block has no parent-child structure or URL. Thus, a global block is perfectly analogous to the database record analog currently common in the headless CMS market.

• “Pages” in Episerver (quoted because the distinction is both minor and optional) can be stored in a hierarchical tree structure, allowing built-in and referentially-integral parent-child relationships between content objects.

• The parent-child model can be preempted where necessary, with content in one node of the tree reflecting content in another node, effectively allowing content to appear in two places.

• Content can be based on other content as a “template.” Content Object B can inherit and selectively override all the content stored in Content Object A, allowing a "base" object with one (or all) content properties modified for use in other environments. Any properties not overridden are inherited.

Key Point Good content modeling is at the core of content reuse and multichannel content delivery. Episerver has a rich set of content modeling options allowing you to express your logical content domain in the most effective way possible.

Episerver is a native ASP.NET MVC application at its core Every CMS rides on top of a stack of technologies. The layer immediately underneath the CMS itself is the web framework on which it’s built.

Web frameworks provide dozens of services by which to build an application – things like user authentication, request handling, and output formatting. These are services that a CMS can choose to use or disregard. In many cases, vendors ignore the provided option and implement their own (for reasons that are sometimes legitimate, but just as often not).

Episerver is built on top of ASP.MVC and has always strived to work with that framework, rather than against it. With every development decision, the Episerver architecture team evaluated what the ASP.NET framework provided, and – in most cases – used that component as part of the Episerver CMS.

This means that Episerver is simply an ASP.NET website that happens to have a CMS and a commerce engine behind it. ASP.NET developers are instantly at home with an Episerver website:

• Content types are model classes, written in C#



6 /9

• Request handling is through MVC controllers

• Templates are simply views, which default to Razor as a language

This means that an Episerver website is naturally extendable in all the same ways as an ASP.NET MVC website.

• Microsoft’s WebAPI standard is simple to implement and fully supported

• Controller actions can return pure data through XML and JSON helpers

• Actions can automatically parse incoming XML or JSON and bind models to strongly-typed classes

Note that none of this is specific to Episerver. This is all supported in the MVC framework, Episerver just doesn’t obfuscate it.

Episerver works with MVC, not against it, so anything you could do in MVC, you can still do, with the full power of Episerver standing right behind it.

Key Point Episerver is simply the keystone on a deep stack of technologies, all of which provide almost countless opportunities to bypass traditional HTML-based content access and provide content as pure data.

Episerver has a powerful event architecture In some senses, the installed state of Episerver is ephemeral. There’s very little in the system that can’t be changed. You can spin every dial, flip every switch, hook every process.

Content in Episerver triggers dozens of events throughout its lifecycle. You can inject and execute arbitrary code when content is created, edited, moved, deleted, approved, or published. This provides a target-rich environment of hooks to assemble, morph, and transmit content into other forms and locations.

Here’s a dirty little secret of headless CMS: it’s usually actually decoupled. Most headless systems don’t actually allow delivery access to the repository. Rather, they have separate APIs for the (1) management of content, and (2) retrieval of content.

What these systems are doing is pushing content from the management layer into content delivery networks (CDNs) for retrieval. The management system responds to the event of code publication by performing an asynchronous process to move content, and, in many cases, you’ll see a delay – it can take up to a minute for published content to appear in the CDN.

This type of decoupled publishing with Episerver is almost trivial. Capturing an event is a straightforward process using the standard C# event model. Events like OnContentPublishing (which executes before publication) and OnContentPublished (which executes after publication) can be hooked with handlers to perform literally any action a developer can think up.

For example, with about a dozen lines of code, you can push structured content into Azure Table Storage or Azure Blob Storage at the moment of publication, with all the delivery advantages those services bring with them.

If a particular set of developers would rather work with their preferred data storage format – be it SQL, XML, JSON, Azure, or anything else – getting content into that system is not difficult. These developers don’t even need to know that Episerver exists at all.



7 /9

Key Point Episerver’s event model allows the platform to serve as a content base which pushes content into any other system through native C# processes that any developer should be familiar with.

Episerver has clear separation between content and presentation Episerver implements an MVC model of content delivery, The Model and View of that paradigm are managed by the Controller. The Controller retrieves the content as pure data and hands it to views to generate output.

The Model is an object instance. In fact, content types in Episerver – of any type: pages, blocks, or media – are strongly typed C# classes, declaratively decorated with attributes. This means what the controller receives from the repository are the same objects that every developer knows and understands.

Views are implemented in Microsoft’s standard Razor view engine by default. However, since Episerver is a simple MVC app at its core, the view engine can be swapped if desired.

Views accept a Model object and use that object to generate output. In this way, the output is always external to the content object itself. Using views to generate HTML is purely optional – these objects can just as easily be serialized to XML or JSON directly in the Controller using existing support for these operations in the .NET framework.

One of the core tenants of MVC – and one which Episerver embraces – is that output is generated from pure data as the last step of delivery. Until the moment the view executes and renders HTML for the response, Episerver content is nothing but C# objects, fully malleable in any way the language allows.

Key Point The separation of content and presentation is not incidental to Episerver. It’s deeply ingrained in the architecture, which means the templating layer can be adapted, extended, or even discarded entirely.

Episerver offers content management at scale

Episerver is an incredibly performant system, which can easily scale through multiple routes. • Episerver has a caching layer built into their repository architecture. On a typical site, 95%+ of requests are

delivered directly from the cache, without incurring the overhead of a database transaction.

• Episerver’s deep integration into the ASP.NET MVC stack, multiple other caching opportunities exist at other levels in the request lifecycle. Controller actions have access to the IIS runtime cache. Additionally, output caching can store commonly accessed URLs via unique URL, querystring, or HTTP header combination.

• Episerver’s DXC Service runs on Azure and uses its burstable grid architecture. Your app can automatically scale outward as load increases, and automatically contract when the capacity is no longer needed.



8 /9

Key Point Decades of real-world experience delivering large websites has given Episerver the opportunity to build caching into their platform at multiple levels, from code-level caching to automatic instance management.

Examples Episerver customers have been extending the system for years using its API capabilities. Here are a few selected examples.

Cross-Platform Personalization for The Royal Agriculture Society of New South Wales The RAS of NSW made Episerver a content hub which uses the an API to pass information between a network of applications, such as their mobile app, their marketing automation platform, their ticketing system, their social media accounts, and iBeacon-based. Episerver houses this information and enables cross-platform personalization to any of the environments.

SMITH’s Caffeinated Commerce Demonstration Experiential Commerce firm SMITH created an example integration for Episerver’s Ascend Conference which used Amazon’s Alexa as an alternate I/O layer to an Episerver Commerce implementation. Conference attendees could simply tell Alexa “Give me a [type of coffee].” Alexa would integrate with Episerver’s API to greet the customer by name, recommend products trending in their area, place their order, recommend a hot or cold product based on the current temperature, and suggest local news to read after the transaction.

Content Management within Line-of-Business Applications A leader in the marketing automation industry powered in-context help for dozens of large web applications using a headless Episerver implementation. Snippets of help text were modeled and stored in an Episerver repository. The technical documentation team made extensive use of Episerver’s editorial, workflow, and preview tools to collaborate on and manage this documentation. An Ajax call to Episerver’s API from within the web applications retrieved the correct help text and displayed it in response to user input.

Conclusion Episerver has traditionally been known as a coupled web CMS. However, the distinction between this and a headless or decoupled CMS is much thinner than the market would have you believe.

Most challenges in content management transcend delivery paradigms. Content still has to be modeled and managed, and Episerver has been solving these challenges for over a decade.

Delivery, while undeniably important, has changed over the years, and Episerver has abstracted the modeling and management of content in such a way that it has continually adapted to these changes. Headless and decoupled delivery is just another step in this evolution.

Additionally, the Episerver platform has deeply integrated into the ASP.NET technology stack, utilizing that infrastructure to its advantage, and developing an API that allows code-level and event-based access to every part of the system. (Consider that our own user interface is simply an add-on over the API core.)

The result is a system well-positioned to provide pure content access to almost any delivery technology in use today. Episerver is a platform on which to build, not a boxed product designed to deliver content in only one way.



9 /9

Deane Barker is Chief Strategy Officer for Blend Interactive.

Deane has been working in content management for over two decades, and in 2016 wrote “Web Content Management: Systems, Features, and Best Practices” for O’Reilly Media (http://flyingsquirrelbook.com).

Blend Interactive (http://blendinteractive.com). was Episerver’s first North American partner, and has been implementing the platform continually since 2008.

decoupled & headless content management with episerver · 2017-05-11 · headless cms is often...

Documents