Towards a better way of working with search in Sitecore using Conjunction
In this blog post, I'll be addressing the current state of using the search capabilities in Sitecore, along with the (hidden) issues this introduces. Finally, I'll be framing out a better way of working with search in Sitecore, whilst introducing the open source project, code name Conjunction.
The current state of using the search capabilities in Sitecore
When working with search features in Sitecore, we as developers normally use the ContentSearch API. The ContentSearch API makes our life easier, since it provides an abstraction over the low level details of working with native search technologies, such as Lucene, Solr or most recently Azure Search.
If you haven't worked with the ContentSearch API before, you can get a basic introduction by following my previous two part series A re-introduction to the ContentSearch API in Sitecore.
At a very high-level perspective, when implementing a search query, you'll be going through the following steps:
- Find out what you should query
- Create your custom search query logic
- Present the search results to the end-user
For most cases, this might be good enough, and often you might consider the task of presenting the end-user with a search result, as being completed.
But, there are some (hidden) issues...
While we are able to build search queries in Sitecore using the methods just described, there are some hidden issues you'll be discovering, as you use the ContentSearch API.
The first issue is the fact that your queries only exists in code, whereas changes to search queries requires both a developer and a deployment. As a direct consequence, the cost of making even small changes are considerable. Looking at this from the perspective of the client's business the time to market is slowed down, and they can't easily adjust to new requirements to gain the competitive advantage. Lastly, the client will also have a hard time trying to fit personalizations into the picture, whereas a lot of business value can be lost by not presenting the right search results to the users visiting the site.
Towards a better way of working with search in Sitecore
First, I would like to enable search query configuration that requires no code changes, meaning that pre-configured search queries can be changed at any given time without the need of a developer and deployment of these changes. The search query configuration should allow specifying nested search query structures for complex queries, such that the solution can handle various kinds of search query scenarios. Additionally, the search query configuration should allow a search query to either react to values provided dynamically (from a query string or an external system), or by using preset default values. Moreover, the search query configuration should also make it possible to vary search queries based on personalizations.
Meet Conjunction
Last year, I gave a presentation at the Sitecore User Group in Copenhagen, where I talked about and introduced a work-in-progress open source project, code name Conjunction. In a nutshell, Conjunction attempts to make this better way of working with search in Sitecore possible, through a feature rich and extensible API. Under the hood, Conjunction uses the functionalities of the ContentSearch API as its backbone, meaning that if you can do something with the ContentSearch API, Conjunction can (or will) support this as well.
Back then, I gave a demo of a working "draft" implementation of Conjunction, that allowed configuring of search queries from within the Content Editor in Sitecore. Once configured, the search queries were loaded into the Conjunction API from a standard Sitecore MVC controller rendering, and finally the search queries were executed against the underlying search engine to retrieve results. In fact, the implementation could even handle getting dynamically provided values from a query string, which the search queries would react to and include in the search queries.
The current state of Conjunction
Since Conjunction was first presented to the public, a lot have happened and I've been busy reworking the initial version of the codebase. This involved restructuring many of the different parts of the API in order to make it more intuitive to work with. In that process, I've been writing several unit tests to verify that the implementation works as intended - and before I forget, I also put in an equally amount of work into getting the documentation up to modern standards, making it easy to get going with Conjunction, and understand how it can be extended.
At the time of writing, I'm finalizing some of the last unit tests and wrapping up the documentation, with the goal of making the first release of Conjunction ready within the next few weeks - at the moment, all the loose ends are being tied up. That being said, I'm really looking forward to show you the result!
Take part in the journey!
Although I am a few weeks short on getting the final details in place, you are more then welcome to drop by the github repo, being that you are either curious about the moving parts of Conjunction, want to be involved or just want to have a peek at what's coming. You can find more details about the current issues over here, and you can follow along the planned milestones over here.
As always, if you got additional details to the content explained in this blog post, or feedback in general, please drop me a note in the comment section below.