On this year's Symposium, Sitecore has announced Sitecore Omni.
With Sitecore Omni you can deliver headless content applications without losing the full personalization capabilities as you are used to with Sitecore. It leverages Sitecore JSS and a new Universal Tracker to build headless applications without sacrificing personalization, analytics, and A/B testing features. It enables organizations to unleash the Sitecore Experience Cloud potential on any device or platform whether it be online or offline.
In Sitecore 9, everything is based on the Sitecore Content repository, which is not new from the previous versions of Sitecore.
Apart from that we can split the architecture in two, we have the page-based content and component output. Next to that we have the query-based content output.
Let us first take a look at the normal page-based content facet of the architecture.
The query-based content output facet is the architecture that ensures that queries can be executed on the Content Repository directly. These queries are for example used to generate a dynamic navigation in Sitecore JSS.
The SDK’s are at the base of the JSS, they ensure a good base of the connection towards the Sitecore API’s.
Three different SDK’s are provided: React, Angular and VueJs. They all have the same functionalities, in regards of React there is also a separate implementation of the SDK for React Native for Mobile App Development.
All of these SDK’s are easy to use and download via the regular Node Package Manager. The SDKs contain the following:
In short, the SDK’s ensure that there is a base setup to use the Sitecore Data into custom created components with the usage of the Sitecore fields, without losing the editing capabilities in the Experience Editor.
The Sitecore Layout Service is the part of JSS that is installed on top of your working Sitecore 9 instance. Is provides the end point on the Sitecore platform where all data is requested and returned.
It provides an easy to use JSON hierarchy of the page, containing the field values and some metadata of those fields. The JSON also provides the Sitecore Context, available for the components to use.
The last part of the JSS is the Server-Side rendering. Historically, front-end frameworks like React, Angular and Vue live on the front-end site of the website. On the browser of the visitor the full page is built and HTML is generated.
Although this takes away the server load on your servers there are some problems with this approach as the performance of the website heavily depends on the device of the visitor. SEO wise it is still unsure how these kinds of apps score, because of their dynamic nature.
That’s why it’s often suggested to use Server-Side rendering. This is close to the traditional way a website is delivered to a browser. It comes in regular HTML, like your current Sitecore website. The HTML is generated on the Server-Side, which means that the device of your visitors doesn’t have that massive effect on performance anymore as less processing power is needed.
This approach is fully supported from the start by JSS. Let’s take a brief look at the lifecycle of a JSS website and Server-Side rendering. For this we have 4 entities, we have the browser of your visitor. The NodeJS environment, which is the server that provides the rendering of your HTML. You can look at it like a regular Content Delivery server. Then we have the JSS App that is running on the NodeJs environment. And then we have you Sitecore Instance with the Layout Service API.
These steps result in a visible website on the browser of your visitor.
After that more data can be needed for one of the dynamic elements on the page. Perhaps there is form on your website. For this to happen we have your framework (React, Angular of Vue) running on the browser itself as well. And then a request can be made to validate the data in the form without doing a full-page refresh.
That concludes our lifecycle. This approach ensures you have the best of both worlds, you have the speed and performance of fully ready delivered HTML to the browser, without having to create a fully separate codebase for your browser only.
If all of this wasn’t enough to convince you yet, then JSS also comes with an Application Import. This part of JSS ensures that your full front end can be built disconnected from Sitecore. After that, the code base can get connected with Sitecore and an import happens. Resulting in new components/templates and pages on your Sitecore instance.
This is a really powerful feature of JSS, as this allows a rapid start of your development team. Having the Front-end development separate from Sitecore as long as possible, so it can stay as close to UI/UX design as possible. And in general, speeding up the time to market of your website.
Do you want to know more about the "Why" of headless? Check out our article: The "Why" of headless and how Sitecore provides the solution