Disconnected Sitecore: A headless and non-traditional approach

“Headless” website architecture is quickly growing in popularity and is impressing both content managers and developers. This approach is something already widely embraced by the Drupal community and something GeekHive wanted to bring to the Sitecore Community to benefit from as well.

At its core, a headless (or decoupled) site isolates the front-end from the back-end, and delivers content through the back-end using an API. This adds a technical layer between what content producers publish and what end-users see.

This graphic illustrates how the site architecture is laid out using the headless approach and introduces the technologies used:

For those wanting to implement this approach in a Sitecore instance, there are several benefits to going headless:

Expanded Talent Pool - Often, front-end developers need to cultivate a deep understanding of back-end architecture to be effective. By divesting back-end and front-end programming, businesses can broaden their pool of potential developers and allow them to focus on their strengths. What this means for your business: fewer constraints and more possibilities for the end product.

Reduced Server Strain - The data delivery server is doing one job and one job only: sending JSON to the front-end.The templates are retrieved from an entirely different server dedicated to making sure the Angular front-end and RESTful backend are pointing to each other.This separates business logic from residing on the client and rendering logic being done on the backend, instead focusing efforts on one task each and speeding up the overall site experience while separating concerns. What this means for your business: better (faster and cleaner) user experience.

Multiple Heads- Looking to build an actual app for a mobile device or RSS feed?Using those same end-points as the front-end uses, these additional features can be stood up in very little time on other platforms. Multi-faceted functionality roll outs with little additional effort, any app or third party integration can then consume the newly introduced functionality. What this means for your business: quicker turnaround on expanding mobile apps and feeds.

Siloed Work - Once an agreed upon data model between the front and back-end developers is reached, both devs can carry on working on their desired tasks and meet up at the end.This allows for work being done in parallel instead of in series. This siloed effort helps in getting a stood up front-end to a client faster as something they can "play with" if some mock data is built in. What this means for your business: faster turnaround to you seeing something working and overall faster to market.

Independent Upgrades - Your UI can be entirely redesigned without back-end changes or disruption. Similarly, the back-end can be restructured without necessitating any front-end changes. This means a reduced risk of refactoring projects, but also that your team must pay close attention to content API design. What this means for your business: unit tests and updates can be rolled out with less disturbance to end users.

Encapsulated in the project below is a "starter kit" for anyone looking to build a website using this approach.It includes:

A Sitecore project intended to be published over the top of an existing Sitecore install, including some example WebAPI endpoints and other helpful examples.

A MVC Project that is intended to run on a different instance/server to act as the head of the site, referencing the Sitecore backend endpoints.

Hi all, I have moved the source to a public repository: github.com/.../disconnected. Also to answer your questions this does not, out-of-box, factor in Personalization and Analytics. That doesn't mean you can't code the endpoints to take those into account: adding an `ActionFilter` or `Attribute` to your endpoints to log and track user behavior for analytics and manually invoke the personalization logic from within the endpoint might get you where you need to be.