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.
