In this series of blogs, Sitecore veteran Bruce Davis-Goff talks about his journey from disillusionment with all-in-one monoliths, his leap to headless CMS and arriving full circle – back to Sitecore.
In my previous blog, I talked about my journey from being a Sitecore newbie 18 years ago, to becoming frustrated with monolithic CMS systems. Along the way I had jumped ship and was basking in the joy of rapid development using React and Vercel, powered by leaders in the headless field, including Contentful and Kentico.
That might have been the end of my Sitecore journey – there was things I wasn’t missing, for example upgrades. Sitecore upgrades have always been something of an embarrassment for me. The inherent flexibility of Sitecore has meant partners could do anything and often did – fun until the upgrade. Twisted piles of technical debt to be unravelled, combined with awkward client conversations, no siree bob, I wasn’t missing that.
But just at that moment..
And then it happened – when you work with a product long enough, whether by design, immersion or osmosis, you become a SME, a subject matter expert. In this capacity, I had been assisting a sister agency who were guiding a Sitecore XP client forward.
It started with an upgrade conversation – “go headless” I implored. The trouble with going headless from MVC is you need a new presentation layer. True, you might extract the HTML / CSS and reuse it, but if you’re rebuilding the front end, a redesign makes sense.
And if a redesign is on the table, you may be up for content remodelling, leading to the possibility of a re-platforming – especially if you aren’t using much of your monolith and there’s big savings to be had.
This decisioning is common to most CMS projects in my experience and the above is a massive simplification – below is a screen capture of part of our in-house decisioning tool which shows a few more considerations. We typically use this tool to assist clients in planning changes to their web presence.
For example, below is a part of a client profile for a simple lift-and-shift to a new platform from EPiServer using the existing content and UI/ UX.
Remarkably, these discussions followed an almost magical path. The customer still loved Sitecore, their editors were reasonably content, and the main driver was their dismal score in customer satisfaction with their site. Ultimately the decision was made to purchase Sitecore XM Cloud, Sitecore CDP, Personalize and Search.
I was the nominated Sitecore architect and was secretly thrilled. As a pure CMS, I believe Sitecore is unrivalled and having spent 3 years doing React, the opportunity to put 2 cool things together was special and intriguing. Maybe like the feeling of seeing your flourishing ex across a crowded room and thinking “damn they’re looking fine”. The opportunity to integrate and work with the new suite of Sitecore products was a gift as well.
So, I knew Sitecore, and I knew React and I was thinking “how hard can this be?”. But you know what they say about assumptions, so it was off to school for me.
The Teacher as the Student
As the Sitecore guy in New Zealand for 5 years, I had trained around 90 Sitecore MVC developers. The training was a commitment, a full week of 9 -5 – 40 hours of training, culminating in the exam.
Sitecore exams have a legendary status; they were never easy and mostly achieved their goal of sorting out the parrots from those who truly got Sitecore development principles.
My first thought when signing up was “how the blue blazes can they fit a full week of Sitecore training into 8 hours?” The course is entitled Sitecore XM Cloud Developer Fundamentals ILT (Instructor-Led Training) and is broken into 2 four-hour sessions, the first called Cloud Administrator and the second session, Local Development, lets rip into it.
Day One
Our instructor was based out of Kuala Lumpa and as expected, the short duration and the broad number of topics, meant he was running like the wind from the get-go. First was the Page Builder – what used to be Sitecore Pages, the interface previously known as Horizon. Shaping up as Sitecore’s preferred editing environment, Pages has received recent welcome improvements such as complex fields such as multi-list getting support.
56 slides later and we’d covered Module one and two – an overview of the Cloud Portal and XM Cloud, the Page Builder, including creating the site collection and site, editing content, designing in Pages, creating low code / no code components, grids, devices, versioning, multi-lingual and more.
At last, with module 3, the meat and potatoes of Sitecore architecting– Content Modelling. We whizzed through creating data templates, inheritance, standard values and some best practice stuff – again at a rate of knots.
Onto module 4, Page and Partial designs – if you haven’t played with these, you’ve been missing the fun. Partial designs, allow for the logical grouping of components, for example the header which may have a call to action, a menu and a search bar. The header could them be applied to all Page designs, all part of the genius accelerator, Sitecore SXA. Pre-SXA, partners had to build this framework from scratch, so there are big benefits and savings from leveraging SXA as much as possible.
Module 5 is Workflow, which covers publishing, and configuring workflows. The new and interesting bit to Workflows in XM Cloud is the ability to create Webhook Validation and Submit actions. When an item moves to a state or runs a command, XM Cloud can send a request to the specified endpoint. On the topic of Webhooks, XM Cloud also allows the creating of Webhook Events triggered by Sitecore system events such as item saved or published. They can fire off the contents of an item as JSON and can be configured to use the rules engine making them flexible and useful for interacting with systems and processes external to Sitecore.
Module 6 is Security, probably my least favourite topic, the less you have to do with Sitecore roles and permissions the better – plug in a Single-Sign-On provider and run away I say.
And that was the end of day one, with homework, create a new project, environment and site called Skate Park before tomorrow, and a recommendation to complete all the labs. The training had been delivered rapidly, there had been no time for Q&A and participants really had to sink or swim. I suspected some students would be beavering away well after the session was finished.
Day Two
Day two started somewhat confusingly, with the intention was to use a third-party sandbox system to provision local development stacks. We had issues with users logging in which blocked that plan. I think the reason for virtual machines is that running up a Docker stack inevitably has a few gotchas. It can take longer than expected due to machine variances and time was short, so it was slides and demos.
Module 2 was serialization. Sitecore Content Serialization, (SCS) is a system for serializing, sharing, and deploying content items, as well as keeping them in version control. It’s the successor to tools like Unicorn and TDS. SCS is simple, fast and does what’s needed – serialize items by database and path, using scopes and rules.
And now, the part you’ve been waiting for!
Module 3: Creating Custom Components, my favourite topic. And it all really starts with the Layout Service, essentially structured JSON delivered via the Edge GraphQL endpoint exposing an item’s data. A component generates the markup by rendering that layout data, simple right? Yes, there more to it than that, but – tick tock.
Next, we touched on routing for Next.js, a file system-based router, that also supports dynamic routes. This is standard Next.js stuff, though it does make an interesting exercise when you combine dynamic routing with Sitecore buckets – here’s one solution: https://www.getfishtank.com/insights/using-wildcard-items-in-sitecore-xm-cloud
XM Cloud JSON Renderings have a cool feature of having a field for their own GraphQL query. This allows you to accurately shape the data that is being returned in the Layout Service for your component saving time and bandwidth.
Styles were next – more SXA smartness. Styles are simple Sitecore items that can be assigned to a component and wrap that component in a named CSS style and can be applied in Pages or the Experience Editor. When you just need to alter the look of a component, (i.e. Blue Background) and not the actual markup or content, they are the way to go.
Rendering out Sitecore fields is up next, and the JSS framework has everything you need here. Understanding how to render out pages, datasource items, setting datasource locations and rendering parameter configuration is a topic unto itself, the official documentation is a good place to bookmark: https://doc.sitecore.com/xmc/en/developers/xm-cloud/walkthrough–building-a-simple-custom-component.html.
Note that XM Cloud also has an app included called Component Builder, this can allow business users to create new Sitecore Components with a no code approach through the Sitecore Pages app, read about it here: https://doc.sitecore.com/xmc/en/users/xm-cloud/get-started-with-xm-cloud-components.html
And the last section is around creating rendering variants. Rendering variant are yet more SXA brilliance and allow you to have a component that can be switched to render entirely different markup using the same content. Read more here: https://doc.sitecore.com/xmc/en/developers/xm-cloud/create-a-variant-for-a-component.html
Just answer the questions!
And that was it, training over. One last task, the exam. The XM Cloud Developer Exam is an online proctored, multi-choice, time-limited, affair requiring the installation of a specific secure browser. You are observed through a web camera and the room you are in must be un-cluttered and clearly visible. You can’t use any reference material, offline or online and you are carefully observed to make sure your eyes aren’t wandering, for example to some cheating cram notes posted on the wall.
The best thing you can do in the exam is use the review flag. Answer the questions, but if you are not 100% sure, flag it for review. This allows you to go back and review question multiple times, until you are as sure as possible. You have 100 minutes, 50 questions and need to score 80% to pass. Here’s a good overview of the exam: https://sitecorewithraman.wordpress.com/2023/12/25/all-about-sitecore-xm-cloud-developer-certification-exam/
This practice developer exam was also quite useful: https://streza.dev/sitecore-xm-cloud-practice-exam/app.html
I passed, I’d love to say with 100% but that wouldn’t be true, I will say it was trickier than I expected, and I did a lot of reviewing.
So, there I was, a previous Sitecore sceptic, back being a fanboy by being immersed in a familiar product reimagined in the cloud. All tooled up, with the latest Sitecore command line tools, a one click docker stack, a blindingly fast and secure CDN via Vercel, smooth CI/CD pipelines, no infrastructure responsibilities, easy API integration and frequent automatic SaaS upgrades – I was feeling zippy.
Ultimately, this was why XM Cloud so successfully pulled me back in, all the thrill of Sitecore without cumbersome infrastructure or upgrades and a fantastic developer experience.
“Wait until the rubber hits the road in the real-world project”, I thought.
And that’s exactly what happened. So, how did that work out? Find out in the next blog in this series – Best of Both Worlds – Real World XM Cloud Lessons
