Sitecore 9 Series
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.
- On-top of the Sitecore Content Repository we have the Sitecore Personalization layer. As all content in Sitecore is personalizable, this is an import part in the Sitecore system.
- On-top of that we then have the Sitecore Presentation Layer, this layer looks into the page item and builds up the layout defined on the item. It builds up the structure that is used further up the chain.
- Then we have the Rendering engine and the Layout Service API. This layer is meant to convert the structured layout into the corresponding syntax. In case of the Rendering Engine it starts creating the HTML; in case of the Layout Service API it converts the layout into a JSON hierarchy.
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 first step here is the Content Search layer, this ensures uses of the Sitecore Index, instead of directly querying the Sitecore Databases. And provides the structured data requested from the Sitecore Content Repository.
- Above that we have the Authentication, because this information is stored in the Index, authentication isn’t considered instantly.
- On top of that we then have the conversion of the structured data towards the GraphQL schema and the JSON/XML based API data.
- This data is then used by the Sitecore GraphQL and Sitecore Services Client interface
- The first important part of JSS are the SDKs, they ensure that the developer can choose a variety of Front-end Frameworks and that there is a starting point in all of them.
- Then we have the Sitecore Layout Service, it’s the technology that is added in Sitecore that ensures a strict API where the content can get requested from.
- When we look further, there is also the option for Server-Side rendering to ensure that SEO isn’t impacted by the decision to choose a headless approach.
- And at last we also have a way to import the application into Sitecore, when a code first approach is taken. Which is a very important part of JSS to speed up the delivery.
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:
- The components that are used to provide editing capabilities when in Experience Editor. A placeholder and text field component are only two of the provided components.
- The basic routing setup, used to match the route with Sitecore
- The content retrieval of the data used by the components.
- Examples on how the provided components can be used and a couple of GraphQL queries.
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.
Sitecore Layout Service
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.
- Step 1: The full lifecycle starts with an original request from the browser of your visitor. He opens up the website, and a request is made to NodeJS, our Content Delivery server.
- Step 2: NodeJS will pass along this request towards the JSS App that is running and bootstrap the Instance.
- Step 3: The JSS App will in his turn start building up the HTML for the webpage and trigger a request towards Sitecore in order to have the Content from the Sitecore platform.
- Step 4: Sitecore will gather the content working his way through the inner layers of Sitecore and return the structured content in JSON towards the JSS App.
- Step 5: With this content the JSS App can have the page fully built and return the HTML towards NodeJS. Which will then send the data over the internet towards the browser.
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.
Interested in what headless can mean for your business?
Do you want to brainstorm about your digital marketing plans and how the headless approach can help you achieve your goals?
Or do you have any other Sitecore related questions?