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...

We are now well and truly in the age of the API, however I feel that there is still a lot of confusion about the best patterns to put in place in how to structure APIs,  There are a number of competing patterns with some overlap and plenty of trade-offs, particularly in the space of building digital systems where the MACH alliance  is gaining momentum.  Some of the patterns you might have heard of include Microservices, Backends-for-Frontends (BFF) and domain services. I personally prefer to think about structuring APIs in terms of the different types of logic the a system composes of and how this impacts the trade-off between pace of change/innovation compared to reuse and stability.  These two forces are in constant tension in enterprise level development, and is well captured in Gartner's  Pace Layered Architecture  concept. Layers of logic I like to categorise the logic implemented a system into four different layers, as shows in the diagram below. ...

A modern digital platform doesn't just get built and then sit serving content pages for years without any changes or updates. Any system where you aren't continuously updating it to meet the needs of the business quickly becomes a legacy system, and other uncontrolled "micro-sites" will start popping up in other places (and all the FXM in the world can't make up for that!). The counterpoint to this however is that constant uncontrolled change to any system can result in a big ball of mud .  When your digital platform is a key organisational asset this might get even worse when you have multiple development teams on multiple releases or across multiple vendors all working on the system at once.  Even when delivering in a single stream using Agile principles your solution can get messy without a clear underlying architecture "skeleton" to which you can add meat. Sitecore's support for modular page composition through placeholders and modules pro...

Sitecore supports having multiple website stored within a single Sitecore instance.   This has a number of advantages for content authors including: It makes it easy to share content between the different sites, and  One DMS database is used for all the sites in the instance it is easy to gather information about users from across the multiple sites and use it to drive personalisation.   However there is a down-side to having multiple sites within the same Sitecore instance, there is one IIS web site containing all the code and configuration files for all the sites in the instance.  This can impact long term support of the Sitecore instance: When you make updates or perform deployments for one site you will impact the other sites in that instance. Whenever the \bin folder or web.config of your Sitecore (or any .NET) site you cause the worker process to recycle, and some deployments (e.g. those requiring breaking code and Sitecore changes across multiple del...