Recently I participated in the round table with Sitecore CTO Tom De Ridder at the latest Virtual Sitecore Symposium 2020 where we discussed the topic of adaptation to the new changes and embracing the experimental mindset. Everything that happens around us is truly a rapid change, and we need to adapt quickly. How can we use technology to facilitate this?

After the panel, I kept thinking about Jamstack as an architecture that facilitates adaptation and how it can be leveraged with Sitecore. Jamstack and Sitecore represent different architectures and approaches, but that doesn't mean they are incompatible.

At Symposium Sitecore mentioned they are evaluating Jamstack. They also offered a demonstration of using NextJS and Content Hub.

This presents interesting options for future implementations, but what about getting started with Jamstack and Sitecore XP now? This is what I am going to explore in this blog series about Jamstack for Sitecore.

If you are used to Sitecore it can be hard to imagine how Jamstack can work. I will describe how Sitecore and Jamstack can complement each other by focusing on four of the biggest benefits Jamstack can bring to a Sitecore implementation.

• Performance
• Scalability
• Personalization
• Front End Technologies

Performance

I like to evaluate a web site based on the Google Lighthouse score. Many developers use that tool to test and see what needs to be improved in the performance of their site. Many factors impact that score, two of the main factors are the architecture of your website, and performance of your application. For a business owner, SEO is important because it improves the chances that your visitors can find your site organically on search engines.

So how can Sitecore performance improve with a Jamstack approach without compromising any of the functionality?

• Decouple your front-end to reduce dependency on the Sitecore page rendering engine, which is relatively slow compared to the way pages are rendered with Jamstack.
• Pre-render your site to minimize the amount of work that must be performed on the origin, thereby improving site speed.
• Decouple your personalization so business users continue to use the Sitecore rules engine to configure personalization, but move the execution of personalization logic off the Sitecore server to the edge or the client, where it can run considerably faster.
• Utilize CDNs to serve your website and take advantage of the global, high-performance delivery networks these vendors specialize in.

In future articles in this series, I will explain exactly how these recommendations can be implemented on your existing Sitecore XP implementation.

Scalability

When we are talking about scalability in Sitecore, I think about these topics:

• Traffic Spikes, Auto-Scaling, Auto-Healing
• Multiple Regions, Failover Groups
• Deployments - CI/CD and DevOps
• Sitecore Maintenance Tasks

From my experience, these are among the most challenging parts of a Sitecore implementation. Every Sitecore implementation is different. Scalability solutions that worked in one implementation may not work in another.

With all of that in mind, how can we minimize the risk of one of those pieces of the infrastructure affecting scalability?

Also, one of the reasons Sitecore customers don't use CDNs more is because personalization and dynamic functionality need to run on the Sitecore server (during the page rendering process). CDNs provide edge-based personalization functionality, and the Jamstack design (the A in Jamstack!) provides the answer to the question "if my dynamic functionality doesn't run on the Sitecore server, where will it run?"

The first three bullets can be substituted with Git + Modern CDN such as Netlify. In this scenario, your complicated DevOps process will be simplified and managed by Netlify.

Even things like personalization, which traditionally have put significant limits on the extent to which a CDN can be used with Sitecore, can increasingly run on CDNs. More on this in a bit.

Completely decouple your front end from the back end will allow you to perform your very time-consuming maintenance tasks in Sitecore without affecting your visitors and jeopardizing having an outage in PROD.

So to sum it up, scalability becomes much easier to handle with Jamstack. Sitecore still plays a critical role in the architecture, but that role is more on the content authoring and experience design side, rather than on the page generation and delivery side.

Personalization

Personalization is one of the main reasons customers are purchasing DXP. But with traditional DXPs, the configuration of personalization is tightly coupled with the page building process. Personalization only works when the DXP executes the personalization rules. The problem here is that DXPs are not high-performance delivery engines. They are relatively slow and inefficient when it comes to doing this. But there are systems out there that specialize in high-performance delivery. You want to take advantage of those as much as possible.

This is what decoupling the configuration of personalization rules from the execution of those rules. Sitecore Experience Editor is still used to configure personalization rules, you will need to have Server Side Rendering always in place, because you will need to depend on your Content Delivery Servers, and all your personalization will happen on the back end.

For your to achieve decoupled personalization, which has a huge impact on performance and scalability as mentioned above, you need to somehow export your personalization rules from Sitecore and deploy them to CDN and make them available on the EDGE.

In the next section I will expand on it a bit more, keep reading :)

Front End Technologies

First I would like to explain the difference between headless and decoupled, these are two different things.

• Headless is like you are playing your music on your Bluetooth headphones. The headphones don't care where the music is coming from. With Sitecore, headless is where Sitecore makes content available to a developer, and the developer incorporates the content into a website that isn't built on Sitecore.

• Decoupled is like you are transmitting your music from your smartwatch to your Bluetooth headphones, but now you moved only your music to your watch, you still hearing the music in your headphones on running trail without having your phone with you. With Sitecore, decoupled is where Sitecore content has been exported together with personalization and served from CDN for faster performance.

Now since you have an analogy of headless and decoupled with Bluetooth headphones, lets try to answer few questions.

Does Sitecore support headless front-end?

Absolutely, you can do it with Sitecore JavaScript Services. Your rendering process happens at runtime, which means you will be using SSR to serve your site, and you are dependent only on back end services, if there are any performance or scalability problems, your site will be affected.

Does Sitecore support decoupled front-end?

In theory, you can do it, but all you will decouple is content you will miss all of the functionality of the DXP. To fully decouple and generate a static site with personalization at build time, the following needs to be done:

• We will need to extract data from Sitecore
• We will need to extract personalization data from Sitecore
• Use NextJS to create a static Site with the data that was extracted
• Finally Deploy it to a CDN

At Uniform we have built the glue to connect Sitecore with modern tools and technologies, enabling you to get the benefits of Jamstack without having to re-architect. Improve the performance and scalability of your current Sitecore implementation, without compromising on features like personalization, while taking advantage of the productivity improvements offered by modern front-ends.

If you want to learn more about Jamstack for Sitecore, feel free to reach out to me on twitter (@tmamedbekov) or request a demo (https://uniform.dev/)

Stay tuned for more articles that are coming soon.



Photo by Jonathan Pielmayer on Unsplash

Photo by Artem Maltsev on Unsplash

Photo by Matt Howard on Unsplash

Photo by Alejandro Luengo on Unsplash

Photo by NASA on Unsplash