Loader

Headless CMS WP LTR 2

Headless CMS WP LTR 2

What you need to know about headless CMSs How to make the right decisions about your content delivery architecture White paper // What you need to know about headless CMSs 1 Published 12/17. © 2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarks of Sitecore Corporation A/S in the U.S. and other countries. All other brand and product names are the property of their respective owners. This document may not, in whole or in part, be photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from Sitecore. Information in this document is subject to change without notice and does not represent a commitment on the part of Sitecore. Contents

What you need to know about headless CMSs 2 Introduction Debates about the respective merits of headless and non-headless CMSs have been ongoing during the past few years. You may well have been ignoring them. After all, CMS architecture isn’t exactly a go-to dinner party subject— even for the most content-obsessed marketers. But this is an important discussion. The quality of the content appearing on audience screens is becoming fundamental to the brand value of most businesses. To maintain an edge over competitors, you need to ensure the experiences you and your developer colleagues create are as rich, smooth, and contextual as possible—and extendable to wherever your audience is, whether that’s on a mobile app or connected device. Headless CMS architecture is a big part of this conversation. So now’s the time to get to the heart of the headless and non-headless debate. In this white paper we’ll explain what headless is (and isn’t). And we’ll look at how you go about making the right CMS decisions for your company—taking into account the needs of both developers and marketers. At Sitecore, we also think it’s time to consider the merits of a third way: one that’s arguably much better suited to the modern age of contextual marketing. Ready? Here we go. What is a headless CMS? A headless CMS is a content management system that lets you store, edit, and manage content—but doesn’t actually render the content on your audience’s screen. In other words, a headless CMS separates the creation, delivery, and management of content (the back-end tasks) from its presentation on the web page, app, or device (the front-end tasks). It has no role in website design, page themes, or templates. By contrast, traditional coupled (otherwise known as nonheadless) CMSs are responsible not only for content creation, management, publishing, and delivery—but also for the lastmile rendering (otherwise known as presentation) of the web page. How headless and non-headless CMS architectures differ So it’s clear that using a headless CMS (rather than a coupled CMS) places a lot of responsibility for the end user’s experience on developers—because how a particular page or screen is built has to be described in code and managed by the developer. But there are some very big advantages to using headless CMSs—and that’s why it’s become such a big deal lately. Headless CMS—a really big deal When the digital world was all about the web and not much else, a CMS could handle authoring, storage, and presentation of designed websites quite happily. Content repositories (which store content and dynamically deliver it to a page) were optimized for HTML templates. Everything was coupled together nicely and there were big performance benefits to this all-round closeness. Then came the mobile revolution and the internet of things (IoT) as well as a proliferation of different devices on the market that didn’t use HTML. Suddenly, the coupled CMS cracks began to show. Their content repositories, which were web-page-centric, just didn’t play nicely with non-HTML formats. They were ill-equipped to use the latest front-end technologies without hacks or significant development work. They simply weren’t ready for an age of fluid and responsive web apps in which pages dynamically update as users interact with them. They couldn’t adapt to a new age of content in which content objects were delivered via an API. Creation of new content and organization of existing content Headless Non-headless Delivery of content to one or more channels Headless Non-headless The actual rendering or presentation of content on one or more devices Headless Non-headless Content management Content delivery Content presentation White paper // What you need to know about headless CMSs 3 Enter headless Then headless CMSs came on the scene and sidestepped all the problems. The agnostic content (no longer optimized for HTML or any other format) was stored and easily retrieved from the headless CMS. Front-end developers, using tools they liked, could take care of the look, feel, and functionality of the user’s experience on web, mobile, or other channels (without having to learn a CMS user-interface technology that was likely to be way behind the curve). Headless CMSs are perfect for an era in which devices had become powerful enough to cope with rendering locally, which in itself brought great UX improvements. Happy developers Headless CMS and its decoupled rendering has freed developers from the conventions and structures of the back end. Now they no longer have to deal with the peculiarities of a CMS’s rendering system and technology—whether .NET, JAVA, PHP, or Ruby. Instead, they can access pure-code fragments of content that are not already in the final representation of the page. Using the latest open-source JavaScript libraries and frameworks, developers can quickly build rich applications and get full control over the user experience. Headless architecture has also made the audience experience smoother and quicker—by moving all the rendering to the devices and streamlining the back end. Meanwhile, marketers enjoy the ability to write once and have their content distributed across all channels. All this freedom and flexibility is huge for businesses. It has empowered them to continually move with the times, innovate, and future-proof their sites. Sound great? Here comes the “but.” The BIG headless compromise There’s a very big downside to headless. Headless CMSs can disconnect the marketer from managing the customer experience—and, perhaps more important—from the data and insights that the customer experience delivers. Here’s why: The decoupling of the rendering (or presentation) of the content in a headless CMS means that before the page is actually rendered, its composition is described in code only. That means marketers aren’t able to create and edit content in context. They can’t enjoy what-you-see-is-whatyou-get (WYSIWYG) authoring. To even reposition a simple component or add a new one requires additional coding. That’s a big problem for marketers. But here’s another as well. The fact that content storage and presentation is decoupled in headless architecture makes it highly problematic to personalize experiences. Personalization requires collection and analysis of customer interaction data from the front end so you can test and optimize personalized experiences from the back end. That requires a lot of custom integration work in a headless architecture in which front and back ends are separated, and even then, some fidelity may be lost. In an age in which marketing in context and delivering great experience is everything, this is a huge downside. There is, however, a win-win-win alternative—a route that’s good for developers, marketers, and end users. The third way—headless nirvana The new, “third way” in CMS architecture delivers marketers, developers, and end users all the best attributes of headless and non-headless CMSs: ■ Front-end developers have total freedom. Unchained by conventions and structures of any back end, they can use their tools of choice to get the most from content. ■ Marketers connect with the content. They can see what they’re creating and editing—and only have to write once to distribute content across all channels. ■ Marketing in context is possible. Personalization and optimizing user experiences through testing becomes easy. This third way is a new type of no-compromise architecture that is at the heart of the Sitecore® Experience Manager (Sitecore XM), the market-leading CMS in the Sitecore® Experience Platform™ (XP). White paper // What you need to know about headless CMSs 4 A new headless architecture Sitecore has always stored content in an item-based repository. In other words, our platform never “pre-bakes” pages ahead of delivery. We’ve kept the creation, delivery, and management of content (the back-end tasks) separated from the rendering, or composition of the web page, app, or device (the front-end tasks). And that’s been true from the very start—it’s what we mean when we say that our CMS “decouples content from its presentation.” This item-based, logically decoupled architecture means Sitecore implementation partners and developers have been able to use Sitecore as a headless system—relying on their own tools to do the rendering outside of the Sitecore server. But they missed out on the opportunity to personalize pages. We wanted to find a way to make it far more straightforward for front-end developers to decouple the content creation and management from the presentation, so they could easily: ■ Maintain full control over the user experience— no matter which sort of device they were delivering content to ■ Use the rendering tools, frameworks, and libraries they wanted ■ Build amazingly rich applications We wanted to deliver all this while still ensuring marketers retained the power to create and edit in context, in a WYSIWYG environment, and personalize content for end users. Happily, we’ve managed to pull this off in Sitecore XP version 9. Sitecore XP 9: hybrid headless perfection In Sitecore XP 9, we’ve introduced two add-ons—Sitecore® Experience Accelerator 1.4 and JavaScript Services Tech Preview—that deliver a new REST API on the presentation layer of the Sitecore CMS architecture. This effectively allows any device or browser to interpret the whole composition of the page or screen of Sitecore content—complete with all the personalization rules implemented by the marketer. Meanwhile, a new JavaScript SDK called JavaScript Services (JSS), allows front-end developers (even those with no knowledge of Sitecore) to use modern JavaScript libraries and frameworks such as React.js and Angular to carry out the rendering of Sitecore content on an end device or browser. These two developments mean the presentation of the content doesn’t have to take place on the Sitecore server anymore—it can be physically decoupled from the creation, delivery, and management of content, yet without any of the downsides normally associated with headless CMSs. The marketer simply composes the page, sends it off for approval, and then the page is ready for delivery to any type of mobile app, web page, or internet-connected device. The front-end developer can either consume the whole page created by the marketer or cherry-pick parts of it before choosing how it’s rendered. In short, front-end developers get the freedom to use the tools they want to deliver audiences a great user experience, while marketers stay in control of the content. At the heart of the headless process is Sitecore’s content delivery engine, which pulls together the components of content into the full screen or page layout before it renders dynamically on the front end. For traditional websites, rendering Nirvana is to combine both the browser and server (known as universal rendering). This means the server can instantaneously render the first page delivered to an end user, avoiding the flash and reload seen in some web apps. Then the browser can take over the end user’s next action (for example, clicking on the nav menu). Because this doesn’t involve round trips to the server for full page rendering, it becomes a very fluid process. Sitecore XP 9 makes this possible. White paper // What you need to know about headless CMSs 5 Here’s how our hybrid headless architecture works Item-based content repository Sitecore Experience Database Personalization rules Rendering server API JSS SDK Sitecore contextual content delivery server Sitecore content management server Form Web hero banner Text box Graphic with caption Mobile device IoT device Browser Content marketer uses WYSIWYG tools to create pages once for any device (attaching personalization rules when applicable). For SEO and performance reasons, the JavaScript application can render on a separate rendering server fully decoupled from content delivery. Each page is composed of small content items (also known as components). Content items (not yet optimized for any format) are gathered in repository. Delivery engine gathers information – ready to be delivered to device or server (or both) for rendering. The Sitecore® Experience Database™ (xDB) delivers context about end users including profile information, past interactions, and more. New API lets any device/ browser consume and interpret page or screen composition AND personalization rules. New JSS SDK lets front-end devs use JavaScript libraries and frameworks such as React.js and Angular to build apps that carry out the rendering of Sitecore content on end device or browser. White paper // What you need to know about headless CMSs 6 Glossary of CMS terms Back-end developer—creates the core computational logic of websites, software, and systems. These are accessed by a user through a front-end system or app. Content object—content is information which is created, as part of an editorial process, for consumption by an audience. A content object is a single piece of this content (like an article or a headline) with its own unique identification number. Content delivery engine—a suite of technologies that helps you control how your digital content is served to your audience. Front-end developer—uses languages such as JavaScript, HTML, and CSS to make the visual part of websites work on computers, mobile phones, and other devices. Item-based repository—a database of digital content objects that allows applications (via an API) to access the content, manage it, and also to modify it. JavaScript—a programming language that makes things happen inside the browser, including interactivity. Think popup windows, Facebook Likes, etc. JavaScript Engine—a program that executes JavaScript code. JSON—short for JavaScript Object Notation, and is the preferred way to exchange information between a server and a web application. It’s an easy-to-understand, readable, text-based format for representing data. OData standards—a protocol that defines a set of best practices for building and consuming RESTful APIs. Using OData means you don’t have to worry about the various data-related definitions. It enables interoperability between disparate data sources, applications, services, and clients. Presentation layer—contains the components that interpret HTML code, JavaScript, and other items passed from the server, and transforms them into what the audience sees on a screen. Rendering—the process of interpreting content data and other items passed from a server into what the audience sees on a screen. REST (or RESTful) API—helps with interoperability between computer systems. Web services that use REST allow requesting systems to easily access and manipulate textual representations of web resources. SDK (software development kit)—a package of software development tools and documentation that helps with the development of applications for a platform. Sitecore JavaScript Services (JSS)—a toolkit for JavaScript developers to build full-fledged solutions using the latest modern JavaScript UI libraries and frameworks for Sitecore in a disconnected fashion and physically decouple rendering from content delivery without losing the value of Sitecore XP. White paper // What you need to know about headless CMSs 7 Contextual delivery The contextual delivery of content is arguably the most powerful aspect of Sitecore’s new, flexible, and channelagnostic CMS architecture. Marketers, using the Sitecore® Experience Editor, simply attach personalization and testing rules to the page or screen. Then this information, complete with attached cookies and identifiers about the end user in question, will be available via the API on the presentation layer. Then when an end-user’s device makes the request to the API, the content delivery engine is able to accept this request and pull information about the end user from the Sitecore® Experience Database™ (xDB), including profile information, past interactions, and other available data. Then the engine can pull components of content into the full screen or page layout before it renders dynamically on the front end. All this means that any rules-based personalization set up on a content component (for example, an exclusive offer on a travel site about a premium cruise which is only presented to visitors with a luxury travel persona) will be applied by the content delivery engine. More control over JavaScript Sitecore’s JavaScript Services is set for official release in early 2018, but it’s available for public preview now. JSS is a toolkit for JavaScript developers that allows them to build sophisticated Sitecore web apps using JavaScript libraries and frameworks. Along with our new presentation layer API, JSS will help bridge the gap between the front end and back end, while helping front-end developers become way more productive when using Sitecore and JavaScript. JSS will offer lots of useful Sitecore abstractions, helping front-end developers map the output of the presentation layer to the final render—whether HTML or something else native mobile. It will help them build fully headless JavaScript front ends that are fully integrated with the Sitecore Experience Platform. JSS will initially support React.js and Angular, but expect more to be supported as time goes by. Bringing it all together At Sitecore, we’re committed to narrowing the divide between back-end developers, front-end developers, marketers, and their audiences—freeing them all to produce outstanding, contextual user experiences on any channel. The release of Sitecore Experience Platform 9 makes further strides by continuing to build on OData standards. This allows you to use off-the-shelf component libraries and software to create content for your audiences without having to worry about the various intricacies of the REST API request, response headers, status codes, HTTP methods, URL conventions, media types, payload formats, and query options. This is part of Sitecore’s journey toward standards-based communication, rather than proprietary formats. In summary, Sitecore’s current products and those in the pipeline offer more control over the delivery, management, layout, and presentation of content—regardless of channel, device, or platform. Meanwhile, reporting back becomes straightforward. And it doesn’t even require separate analytics tools. Your next headless move At Sitecore, we’ve always believed headless should be a win-win-win—for marketers, developers, and the customer. We think that by delivering this triple win, we’ve reframed the headless debate. The headless CMS approach will increasingly prove invaluable to many organizations—but there’s no longer a need to endure the traditional downsides. When deciding on CMS architecture, businesses should now be asking a simple question: How does this CMS empower marketers and developers to deliver the most rich and contextual experiences to their audiences? White paper // What you need to know about headless CMSs 8 Next steps We’d welcome the opportunity to hear about your plans for headless. Reach out to us via: ■ Email: sitecore.net/contact-us ■ Phone: sitecore.net/phone ■ Chat: sitecore.net/chat ■ Or request a demo here. If you need further help with understanding Sitecore’s decoupled architecture: ■ visit Sitecore Documentation ■ give your account manager a call ■ or check out Sitecore training to book an online or in-person training session. About Sitecore Sitecore is the global leader in experience management software that combines content management, commerce, and customer insights. The Sitecore Experience Cloud™ empowers marketers to deliver personalized content in real time and at scale across every channel—before, during, and after a sale. More than 5,200 brands—including American Express, Carnival Cruise Lines, Dow Chemical, and L’Oréal—have trusted Sitecore to deliver the personalized interactions that delight audiences, build loyalty, and drive revenue.