Decomposing the composable, Sitecore Composable DxP the buzz around

 Hi Team,

You must be hearing a lot about what is happening around Sitecore ecosystem, There have been lot of talks, Presentations around "Composable DxP" and whole Plug-n-Play architecture where Sitecore is moving (Already moved i would say :))

And if you are a sitecore technology enthusiastic, then you must have started connecting all the DOTS....Where there have been lot of acquisitions of other third party vendors for good reasons, and there have been lot of investments happening just to make sure that the Sitecore eco system is thriving and is compatible with whole composable world we are going towards.

Also Sitecore is working behind the scene to launch the most awaited product called Experience Manager (XM) Cloud, A SaaS based services , Take a look at my blog on https://daivagnananavati.blogspot.com/2022/08/getting-started-with-xm-cloud-step-by.html of getting the XM-Cloud introduction repository into your local and explore.

In today's blog post i just wanted to make sure that, i will try to explain different terminologies and the new buzzwords which are coined and anyone from a developer to someone who is experienced but have not been able to follow things around headless or anyone who is orchestrating their path towards DxP and whole headless and XM-Cloud journey, should be able to understand these buzzwords, As it will help in understanding all the articles and blog posts around the whole paradigm shift that is happening.

So, What i am planning in this blog post is to let our fellow developer understand these terminologies and why they came into picture, and then my upcoming blog posts will show "A path to XM-Cloud" or the steps which we took in our project to decide what are the processes and through discovery involved around going from totally monolith to headless and finally towards XM-Cloud, I hope many of us will be having same questions so it will help other also to follow the same or similar process for their organization or work.

NOTE: If your target is to go to XM-Cloud or upgrade your current code base to XM-Cloud, You have to go headless first, because XM-Cloud works on headless way, my next blog posts will be talking about it but that is why understanding headless and its buzzwords are important.

And to know what is headless we will need to first understand what changed from traditional CMS and if it changed what are those tools using which headless CMS is possible.

No head? Or no body? Why its called headless?

Ever wondered why its called headless? and why going headless is important and what challenges it solves? 

This is not something which is not discussed but it is always good to know before we implement something and know why we are doing it.

Bottleneck issue with traditional Sitecore CMS is that data and presentation both are tightly coupled, so when a request is made our CMS pipeline tries to combine both before the page or component is rendered and this process typically takes little time until final output is rendered in a browser and it gives sense of slowness for known reasons.

Now, Think about if we can just remove front end part or presentation ("Head") from content ("Body"), so front end which is complied HTML mark up will be created by developers and it will be filled up using APIs which will drive content and fill out content into them, This will significantly reduce time of rendering the final output, This is what headless is, removing the presentation dependency from CMS and let the best UI framework handle it and use CMS as content repository and a content provider. 

Now, we know about headless and how it works, So next step is to understand the terminologies and building blocks around it to achieve headless in Sitecore.

 

Buzzwords

MACH

This is at the core of all the composable DxP, MACH is the reason which gives us the whole composable and decoupled and plug and play way of working, I personally learnt what is MACH when i did my Order Cloud certification.

MACH architecture is a set of technology principles behind new, best-of-breed technology platforms. The acronym stands for Microservices-based, API-first, Cloud-native, and Headless:
 

• Microservices: Individual pieces of business functionality that are independently developed, deployed and managed.

• API-first: Very self explanatory, API is at the center of everything in these MACH complaint apps,  All functionality is exposed through an API, making it possible to tie together two or more applications or services.

• Cloud-Native SaaS: Software-as-a-Service that leverages the full capabilities of the cloud, Functionality is updated manually, eliminating the need for upgrade management.

• Headless: The front-end user experience is completely decoupled from the back-end logic, allowing for complete design freedom in creating the user interface and for connecting to other channels and devices.

Layout Service

A very detailed understanding is given on https://doc.sitecore.com/xp/en/developers/hd/190/sitecore-headless-development/layout-service.html but if i were to define it in a quick and easy way, "It produces structured JSON output, by decoupling layout and rendering, and allowing us to render Sitecore components with any front-end technology stack capable of consuming JSON data"

Import Service

Import service is specifically helpful or rather supports code first development environments where it provides an endpoint on the Content Management (CM) instance, enabling developers to import an application created and defined structurally while disconnected from Sitecore.

Rendering Engine 

Rendering engines render content and layout data returned by the Sitecore Layout Service from a Sitecore instance, So now that you know the drill, Basically import service has all the items from Sitecore tree, and those are being fetched by layout service in structured format from Sitecore instance and then rendering engine renders them.

XP (Experience Platform)

There have been a lot of research & arguments around XP vs XM and which one to go for, Because sitecore comes with both the options, So its on us to identify which fits the best, First let's see what is XP (Experience Platform) 

This is the full fledged offering from sitecore where it includes All personalization in details with all rules, marketing features, Full cortext, Marketing automation etc.

So its all in one offering where you get everything in the box.

XM (Experience Manager)

This is a subset of XP, so this is CMS only offering from Sitecore which is lightweight, With its introduction there have been lot of things which got removed in the package of XM from XP, and it is a good choice if we are not using too many analytics features or marketing features, It comes with all other goodies like sitecore forms,  WYSIWYG editor and much more.

NOTE: There are OOTB personalization rules available so its not completely removed, there is little personalization you can still do in XM.

Experience Edge 

Experience Edge is an API-based service from Sitecore that gives you globally replicated, scalable access to your Sitecore Experience Platform items, layout, and media. You can use the standard publish tools in XM , but instead of rendering content from a self-hosted Content Delivery environment.

Experience Edge provides you a Sitecore-hosted GraphQL API. You can build your solution in any language and pull the content you need to power it with GraphQL

Experience Edge for XM acts as a publishing target for your Sitecore content and media, and provides a GraphQL API:

Experience Edge also provides a CDN for your Sitecore media library that supports media resizing and manipulation using query string parameters that mirror those of the existing Sitecore media handler.

Unlearning here is : In headless XM topology there is no content delivery role (As i said its unlearning to learn something new),  It has different way of working, for which "Experience Edge" comes into the picture.

 GraphQL

To cut the story short, It is a hosted API using which we get some data, fair enough right? but it is much more than that, and why its important to know is because it has some sitecore specific features too (you can use any data source, here we are taking about sitecore)

We can do following thing using GraphQL

• You define endpoints with absolute URLs

• These end points understand the GraphQL language or a query.

• The GraphQL type system knows about Sitecore templates

• Template changes are updated in real-time

• Traverse the content tree by ID or path.

• Get a snapshot of the Layout Service output for a route, for use with Sitecore Headless SDKs such as the Next.js SDK.

• Perform Boolean queries for items based on field values and other item properties.

Horizon 

If you are like me the only editors we knew were content editor and experience editor, but as paradigm is changing we now also have "Horizon" 

Which is the next-generation editor in Sitecore Experience Platform. Couple of things about horizon

• Introduced with 9.3 as a separate installation compatible with 9.3+

• The page editor, which you use to create and edit web pages. As you edit a page, you can see how it will appear on different devices.

• Simulator mode, which you use to preview web pages as they will appear on different dates and on different devices.

• Insights view, which you use to see analytics for your web pages.

Front-end as a service ("Symphony", "Sitecore pages")  

When i hear a word "Symphony", i visualize "Musical orchestra", That also means many instrument working in harmony to create on tune.

 

I think at first i was so confused between all of these, "Sitecore horizon", "Symphony" , "Sitecore pages" Because they all look same with little difference, so i will put this topic on my readers to come to a conclusion, Because i do not know when something will be obsolete and something else will introduced.

 

The purpose of all of them is to give seamless UI experience to content authors.

Vercel

Vercel is a technology partner of Sitecore and provides scalable solutions to the organizations reducing the overhear which was needed previously for sitecore application deployment.

• It works with over 30+ different framework.
• Front end development activities are not solo anymore, Vercel makes it collaborative.
• Already have website templates built on next.js which are ready to be deployed
• Supports automatic deployment and CI/CD.
• Support of integration out of the box available with vercel like google lighthouse, Slack etc.
  

NOTE: They are creators and maintainers of Next.js, the world's leading React framework, So its obvious choice for sitecore headless apps (And that is the reason why we are talking about it ;-) )

If you see below diagram provided on https://doc.sitecore.com/xp/en/developers/hd/200/sitecore-headless-development/architecture-overview.html , All the working parts are shown and which will give you a better idea of how things work.

I know that all of these are not new but if you ask me, i was so curious to know one term a day, every morning i used to hear something new from sitecore, some new word, some new tool for solving some old problem :) and hence instead of assuming that everyone knows this, i just did a blog post where i had all these under one blog post 

 

My next post i want to talk about what research helped us in "Discovery on monolith sitecore to composable DxP", It will be a business case, but to understand that, it was important to understand all these BUZZWORDS, and after that my target is to show how it all ends up in XM-Cloud and how it works, and all things about XM-Cloud.(But its a long journey and not immediate)

 

I hope it make sense to all of you !!!