Digital Learnings in Sitecore & Cloud

We've been working on a large headless solution recently that utilises Sitecore Experience Edge for XM. We are working in a micro-front ends architecture, with some parts of the site leveraging Sitecore JavaScript Rendering SDK (previously known as JSS) for delivering pages whilst supporting full inline editing and page designing. Other parts of the site use GraphQL queries via backend-for-frontend (BFF) style APIs to pull back content. Both these approaches leverage Experience Edge for serving GraphQL however the nuances of how they are implemented need to be understood because we have found they lead to some different behaviours that can impact the way content editors need to use the system. The point of rendering One of the most important things to understand about Experience Edge before you start using it is that for performance reasons it does a lot of work at the point of publishing, that used to happen at the point a page was rendered when using Content Delivery instan...

Sitecore JavaScript Services (JSS) was launched, now a few years back, as Sitecore's solution for meeting the needs of doing headless content mangement on Sitecore using JavaScript, without losing the key capabilities (especially in line editing) which makes Sitecore great. It consisted of JavaScript SDKs that worked with the JSS layout service running on Sitecore. Now renamed the Sitecore JavaScript Rendering SDK , and supporting the JSS services or Experience Edge, this SDK is an important part of delivering JavaScript web apps leveraging Sitecore editing capabilties. That said, for a lot of front end developers JSS is a skillset that they might not know a lot about. Using it properly requires not only an understanding of how to install and work with the SDKs, but also understand Sitecore concepts such as placeholders. Furthermore not all web use cases, even those that leverage content, benefit from such advanced capabilities. Benefits and complexities I see the followin...

The Sitecore product family now provides two key platforms where you can manage content (and technically this is now expanding as you can manage content in Sitecore Send and Sitecore CDP as well -- the future for these is unclear however I'd expect the patterns below may well expend to those other delivery channels in a similar way).  When you have platforms with overlapping capabilities, I believe it's always important to have some clear principles as to what the role of each system is in the overall architecture - so you know what you should and should not do in each place.  I guess it's kind of like putting together a recipe to follow when you are making decisions to ensure that everything works together and you don't end up with a failed cake. Below I outline one way that I feel makes sense to align the responsibilities between Sitecore XP/XM and Content Hub in an enterprise digital architecture. The moving parts The Sitecore tools that we're considering are ...

In my last couple of posts I've talked about when to choose a multi-site versus a multi-instance pattern for deploying Sitecore, and how we approach delivering Sitecore platforms using feature based modular development . In this post I'm going to take a look at the sorts of issues that arise when large global organisations start to look at rolling out digital platforms, and how some we can leverage some of the points that we've covered in the last couple of posts as a part of our approach to designing a Sitecore based digital platform architecture that addresses them. Tyrannies of global size Large organisations hosting a number of different websites are often confronted by some competing forces which lead them to ask about whether they should have multiple sites in a single or multiple Sitecore instances.  These are usually related to the following requirements which address different types of web presence for different parts of a business: We have different site...

I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec...