Skip to main content


Implementing Composable Search for Your Site: Manual DIY Approach [Part 1]

Binoculars On Top Of Rock Mountain At Beautiful Sunset Background.

Over the past decade, we used to rely on old good ContentSearch API, but sadly or not – it will not stay with us on a journey to a bright and shiny composable world.

In this blog post, we’ll compare the alternatives to it and help you choose the one that better suits your requirements. I list these options by the growing number of features and decreasing complexity of implementation:

  • Manual implementation, also known as DIY-approach (this part)
  • SearchStax Studio (part 2)
  • Coveo (part 3)
  • Sitecore Search (part 4)

Before proceeding, let’s define what we mean by saying composable. First and most, a composable solution is an external system that integrates through the web API and other than that is a totally standalone piece of software, potentially a black box written on any possible language and technology. That is why the “API” suffix of ContentSearchAPI is a misleading term here, as it works within the same runtime as the Sitecore Content Delivery platform itself.

To make this use case even more complex, let’s assume we have a non-Sitecore source of data to consume (let it be Content Hub) and present as the result of a unified search experience.

There are two potential options for how we can implement this:

  • Traditional approach using CD server(s)
  • Experience Edge approach without CD server(s) – this approach is used with XM Cloud

Traditional Approach

First of all, we need to create and configure several search indexes, at least one for content from Sitecore and another for index documents from ContentHub.

On the Sitecore side of things, we need to intercept publishing content and index it to a Sitecore-related index. This can be done by subscribing to publish:end event with either webhook (for 10.3 or newer) or adding an additional publishing processor to Sitecore pipeline (for older versions) pushing Sitecore content into the Solr index.

On the non-Sitecore side, one can implement Azure Functions (or similar) that trigger content crawler indexing content into a non-Sitecore index.

So now we have both types of content indexed at their own indexes, so we can configure a unified search mechanism in Solr using sharding and common schema.

But how does content appear on a page? Since we got a headless implementation, we must build the search-related components (likely with React) to display search results/facets/etc. on a page. These components are tightly integrated with the head application that is responsible for “converting” everything coming from UI into search queries. That means we also need to build custom APIs.

Pretty complex, isn’t it?

Experience Edge Approach

Unlike the previous example, we will not build our own indexes to absorb the data from Sitecore and Content Hub, nor create any custom APIs for that purpose. We will instead implement search directly at our head application which comes to dual search implementation: one to search through documents at ContentHub and another for Sitecore content published to Experience Edge:

In order to search Sitecore Experience Edge we can rely on Sitecore GraphQL query API implementation. The issue here is that it could perform only basic operations and a lot of desired features are missing – such as faceting, boosting, etc. Also, it is worth mentioning that Edge comes with a read-only GraphQL schema that is designed to accommodate common front-end use cases for headless Sitecore development. Content gets published “flat” into it and it exposes limited information about Sitecore items.

Content Hub also features its own Search API. that could be utilized to bring the results.

The biggest implementation challenge of this approach falls to our front-end head application. It should be fully responsible for unifying the reach results, reasonably caching repetitive search requests, also additional search logic configuration. And yes –  one still needs to create React components for user interaction on a page.

In addition, you definitely would want to have analytics as part of your solution – you’ll need to implement event collection and push it to your preferred monitoring system that accepts external events via API.

To summarize, despite both options of the above DIY approach making sense for some basic headless implementations, it seems naturally clumsy for a truly composable world where the expectation is for us to “compose” the desired system from a number of relatively ready-to-use blocks, where the biggest effort falls to configuration and integration.

Up Next

So with the next post in this series let’s see what options the market offers us, starting with SearchStax Studio.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Martin Miles

Martin is a Sitecore Expert and .NET technical solution architect involved in producing enterprise web and mobile applications, with 20 years of overall commercial development experience. Since 2010 working exclusively with Sitecore as a digital platform. With excellent knowledge of XP, XC, and SaaS / Cloud offerings from Sitecore, he participated in more than 20 successful implementations, producing user-friendly and maintainable systems for clients. Martin is a prolific member of the Sitecore community. He is the author and creator of the Sitecore Link project and one of the best tools for automating Sitecore development and maintenance - Sifon. He is also the founder of the Sitecore Discussion Club and, co-organizer of the Los Angeles Sitecore user group, creator of the Sitecore Telegram channel that has brought the best insight from the Sitecore world since late 2017.

More from this Author

Follow Us