Headless in the Cloud? What is Gained, What is Lost in “Headless” Sitecore Implementation

August 12, 2015 | TBG Front-end Development & TBG Tech

surrealist man with no head like magritte paintingWhat is a Headless CMS Implementation?

Headless websites use content management (CMS) technology for the back end, but not for rendering what the end user sees in the website or Web app. Deciding to build your own custom front end (the missing “head”) has both advantages and disadvantages. This blog post will give some context and evaluation of the approach in the context of Sitecore, the leading .NET content management and experience management platform.

The industry is buzzing with excitement about new types of site and application behavior, and headless implementations open up these possibilities—while simultaneously changing the way Sitecore works. If you install a headless Sitecore implementation to the cloud (for instance MS Azure), presto, you have a scalable centralized content repository that can feed structured content into n-many Web or native headless apps.

CMS platforms (or WCM, or Experience Management, or what-have-you) traditionally offer many different capabilities. At least since the waning of the dinosaur Java “portal software” that required you to build your own JSP front end 10 years ago, one of those elements has been to provide a “front end,” consisting of the technical mechanics needed to render the user experience of websites or Web applications, usually through standardized templates.

To break it down, traditional CMS infrastructure includes elements like:

  • A templating system, that combines managed content with pre-fab presentation code to produce the final user experience.
  • URL management, relating content to a stable, referenceable Web address.
  • Link management, so that links within pages always point to real pages and are never broken within the CMS-served site.
  • Dynamically generated content presentation, as in multivariate testing and personalization, in the systems that support those features.

In a headless CMS implementation, it is proposed to dispense with these CMS processes and replace them with something simultaneously simpler, more modern, and more custom. Rather than use the CMS subsystems to render the front-end experience, the experiences are generated within richer JavaScript applications downloaded to the user’s browsers. Here, the CMS continues to manage content and content relationships, but it no longer participates in the business of creating front-end experiences. In headless, the rendering and business logic of those front-end experiences no longer are rendered on the CMS server side before it is sent down the pipe to the user.

The front end of the headless website or Web application is typically custom built through a combination of HTML and one of the current advanced JavaScript frameworks (today the likes of Angular, Ember, Backbone, and React), shifting the majority of the presentation logic to the user’s browsers. (Note that Ember and React also support server-side rendering of HTML, another complication that can lead to scenarios that are more flexible). This blog post is about headless implementation in the context of Sitecore, and specifically about the pros and cons of such an approach.

A Digression on the Origin of “Headless”

Headless implementations seem to have arisen as a trend in the context of Drupal, the popular Open Source CMS, which makes a kind of sense. Because of Drupal’s origins as a quick site builder product, Drupal’s front end has always been relatively intertwined with business logic, relatively code-heavy, and substantially determining of the direction of user experiences that Drupal easily supports. As modern user experience expectations have sped up their rate of change, one can only imagine the dis-efficiencies that occur trying to refactor nuanced interaction design and other elements into the complex theming system of Drupal. At the same time, the Drupal development world tends to have a high affinity for modern front-end technologies and standards, so one imagines the two forces coming together in a rich way. It’s not a wonder that the idea of headless implementations would arise in the Drupal ecosystem.

Sitecore, being the other extreme from Drupal in regards to being front-end-flexible—being very good at supporting nearly any user experience but slower to develop sites—has a different relationship to headless implementation. Headless implementation is not a cure for your common-rigid-templating-system-cold; but it still has the potential to address some interesting limitations of the conventional CMS-website-development setup.

How Does a Headless Sitecore Implementation Technically Work? 

Although there may be variant approaches, the core of headless Sitecore implementation is to build rich JavaScript applications that download from Sitecore or another Web server as a single file or small collection of HTML and JavaScript files. These files then get the managed content, topical metadata, and other meta-elements like tree structure from either the Sitecore Item API, or a secondary API custom developed on top of Sitecore specifically for this purpose. Below, we have provided an example of a call to the Sitecore Item API to get content:

// an Angular "service"
angular.module('myApp.services').factory('MyModule', [
    '$resource',
    function ($resource) {
        MyModule = $resource('', {}, {
            getSomeComponent: {
                url: 'http://www.berndtgroup.net/-/item/v1/?scope=c&query=%2Fsitecore%2Fcontent%2FTBG%2FThinking%2FBlog%2F%2F*%5Bcontains%20(%40Blog%20Category%2C%20%27%7B28DEECA5-D32C-46AA-BF2F-12FF95F48422%7D%27)%5D%27)',
                method: 'GET',
                isArray: true,
                cache: true,
                transformResponse: function (response) {
                    // an example of dealing with variable responses
                    var myNiceData = JSON.parse(response);
                    if (!myNiceData.item_id) {
                        return myNiceData;
                    }
                    myNiceData.collectiontOfItems.forEach(function (item) {
                        item.uiIndex = parseInt(item.item_id, 10);
                    });
                    myNiceData.collectionOfItems = myNiceData.collectionOfItems.sort(function (a, b) {
                        return a.uiIndex - b.uiIndex;
                    });
                    return myNiceData;
                }
            }

            getAnotherComponent: { ... }
        }
    }
]);


All aspects of the front-end experience, including URLs, persistent elements, and interaction with browser behaviors have to be handled by custom JavaScript programming, most typically developed in one of the new, robust JavaScript frameworks mentioned above. These frameworks make creating rich application-like behavior easier, and support interaction patterns with the server/CMS that go beyond following links and loading pages—in fact, they are optimized for more complex interactions.

This code pulls content from the Sitecore repository along with metadata, tree location and content relationships. It then formats it for display, creating all of the contextual elements, if they are needed, that are usually provided by the browser/page relationship. Of course, the new JavaScript application need not replicate the experience of traditional page browsing (the classic interactions of link, page loading, URL switching, etc.), a flexibility which is one of its key strengths.

surrealist door and sky image with web development termsWhat is Gained, or Made Easier, in a Headless Sitecore Implementation?

So, what benefits are gained from taking the idiosyncratic approach of a headless Sitecore implementation? Certainly, they are contextually specific, but to generalize, we have created what we think is a prioritized list of the benefits:

1. Leaving Behind the Classic Browser/Page Experience Relationship

The sort of richer, instantaneous, application-like behavior can more easily become the focus, which may in some cases be easier to implement where traditional Web browsing considerations are not defining of the interactions. In many ways, this harks back to what people did with the now dated acronym AJAX and still do more with modern MVC frameworks—a paradigm that Sitecore happily also supports.

2. Shifting Rendering & Business Logic to the Browser

There may be benefits to offloading the computation of highly personalized, computationally intensive page rendering to myriad users’ computers. Instead of evaluating thousands of unique calculations on a server farm, these calculations can take place on all of the computers that are connecting to the server, distributing elements of the business-logic-rendering-load. Of course, there are pronounced exceptions to this—like the business of querying large search indexes, which have to happen on the server and cannot happen over the Internet, for performance reasons.

3. More Rapid Development, in Some Cases

For single-purpose Web apps, there are cases where headless development can mean faster time-to-market, especially when the UX requirements are less page-based and fit more into Web-JavaScript-application frameworks. Another case is where the delivery of the Sitecore-managed content is a hybrid native app—where a smartphone app is built using an adaptation of Web technology (such as HTML + Angular.js).

4. Changing Who Can Work on Development

One of the holistic changes implied by headless implementations is a shift to development of business logic and queries in front-end code. In some circumstances, back-end developers accomplish this, but more commonly, it means that the front-end developers can now participate in a greater share of the project. Since front-end coding is rapidly maturing to the same level of complexity of back-end, and since JavaScript-savvy, resources are a growing population that currently cost less than ASP.NET devs, there may be some business sense in a proportional shift of work to these resources.

men and web development terms floating in the skyWhat is Lost, or Complicated, in a Headless Sitecore Implementation?

What these implementations leave behind is substantial, since Sitecore provides a great deal of useful functionality that interacts with the front end through its various templating and editing subsystems. While it may be possible to custom develop some of these features, it’s doubtful that the majority of them will ever be addressed. A headless Sitecore implementation will say goodbye to:

1. Sitecore’s Multivariate & Personalization Capabilities

One of Sitecore’s most exciting aspects is its advanced personalization and multivariate testing feature set, especially powerful in Sitecore 8. None of this functionality is available when the front end is directly rendering content from the Sitecore API—all of the relevant layers are missing. Therefore, in this context any personalization or multivariate testing has to be handled in one of two ways. Testing either has to be hard-coded into the JavaScript “head” (not a great idea from a level-of-effort perspective because they would need to be relatively custom per case, as opposed to Sitecore's developer subsystem). On the other hand, it may make sense to take a less severe approach to embedding Sitecore content in remote applications, like Sitecore FXM, which is not, strictly speaking, a headless approach but supports these features, and is discussed at the end of this blog post. Trying to get around this limitation would take a fair amount of complex custom programming.

2. In-Context Editing

Although developers often undervalue it, the reality is that for many rank-and-file CMS end-users, “in-context” editing (where user’s add/edit/delete content through the front end of the site) is still a crucial time saving (and confusion-reducing) feature. All of the functionality of in-context editing, including advanced features, are dependent on Sitecore JavaScript that disappears in a headless implementation.

3. Caching for Performance

Since the architecture of a headless implementation bypasses Sitecore’s final HTML caching system, you have to rely on lower-level, API data caching, which is at an early level of assembly—and therefore, there are assembly operations to create the final HTML that won't be cached. Performance results may vary.

4. Sitecore’s URL Generation

In typical development, Sitecore handles URL states, which are both a key piece of usability for some users and important for bookmarking. While it is possible in headless implementations to recreate traditional content relationship (tree structures, and lateral linking via topical metadata) via queries to the Sitecore item API, the baseline does not replicate Sitecore’s URL mappings.

5. Easy Analytics, Content Profiling

Another feature of Sitecore’s front end is the ability to easily add goals to pages (tagging them as conversion points) and to profile content (in order to reverse engineer user interest from content viewed)—neither of which works without the Sitecore front end. Further, though it is entirely possible to embed Sitecore or, say, Google Analytics events in a custom front end, the ease of page-based tagging, Google tag manager, and the like is lost when the rendered page itself evaporates. It becomes a complex problem to determine how content viewed should line up with analytics events.

6. Forms for Marketers

Sitecore’s forms-as-content manager also depends on the Sitecore front end. Without it, forms need to be achieved another way. Web Forms for Marketers relies heavily on Sitecore’s front-end code generation.

7. Transparency of Downstream Development

As front-end functionality moves into more custom JavaScript frameworks, and away from Sitecore’s standard templating, rendering, and other subsystems, there is a danger that headless sites may be more difficult for the next developer down the line to pick up and run with. As always with custom development, basing decisions around some sort of standard, and documenting are the best ways to mitigate against these possibly necessary evils.

So, to summarize, a lot of what makes Sitecore great goes away with a headless implementation. What is gained is also interesting, and in some cases, brings significant business value. However, it is important to mention that it is not an “either/or” situation, in two senses.

First, it is possible to embed headless experiences in traditional Sitecore sites, so that a template downloads from Sitecore that provides a rich all-in-one experience as a subsection of a larger conventional site. Second, it's possible to have headless experiences or applications live side-by-side (on different URs) with conventionally rendered sites, sharing the same content— headless hybrid native apps are a straightforward use case. For these reasons, headless implementations can be a high value addition to an existing Sitecore environment that more conventionally leverages the platform.

Coda: What About Sitecore FXM (Federated Experience Manager)?

One the best new technologies that Sitecore has launched in the last year is FXM—a great system that allows Sitecore templating functionality (including caching, advanced tracking, and contextual rendering for personalization and multivariate) to be embedded in non-Sitecore sites.

While not formally a headless approach, FXM may meet some of the needs that would drive an organization to consider a headless approach. FXM is perfect for cases where content from the Sitecore repository needs to be leveraged across remote Web properties and applications built in other technologies, but where the UX needs are not particularly custom—and therefore, cases not benefiting from a more open custom front end. In those cases, FXM provides a solid solution that also provides the other niceties of the Sitecore platform to sweeten the deal.

FXM provides some of the gains from headless mentioned above, though in a limited fashion, and needs to be relevant in a relation to the overall project content for suitability. Like headless, it shifts Sitecore experience rendering into the front end, but unlike true headless implementations, the paradigm of content delivery is still remains conventional, and front-end process remains more closely aligned with traditional Sitecore development.

About the Authors

person's silhouette with puzzle pattern
TBG Front-end Development

TBG’s front-end developers have chops that are right on the edge of the newest acronyms, but at the same time, they are deeply planted in the values of efficient production & supportability of code. There’s no tangled Web with TBG’s Front-end Development team!

person's silhouette with hex grid pattern
TBG Tech

TBG’s Technical team is always on the cutting edge of Sitecore, ASP.NET, & new deployment technologies. There’s always a smarter, faster, better way to reach solutions, & we may die trying to find them.

Leave A Reply

comments powered by Disqus