Review Of The Different Search Providers Available To Use On Your Episerver Project

Picking the correct search provider for your project can be an arduous task. Episerver comes bundled with a ‘basic search’ out the box, but, depending on your requirements this can be too limiting. Episerver also has a third-party search add-on that lives in the cloud and provides a lot more power and functionality. In today’s post, I’m going to review the main search provider options that I’ve come across when architecting an Episerver project.

Which Search Provider Should I Use With Episerver?

Deciding on which search provider to use on a project, mainly depends on these criteria:

  • Do you want to self-host, or, cloud host?
  • Is all your search content in Epi?
  • Will your site be in a load balanced environment?
  • How important is searching in terms of your websites aim? If most of your website’s traffic comes from Google, will a basic search suffice?
  • Do you need to index different types of content? If you sell/have products you sell to your users, will you need to index this specifically and be able to filter on specific product attributes
  • Will you search combine data from multiple sources?

Based on your websites requirements will determine which provider is most appropriate to your project.

EpiSearch

EpiServer provides a free search addon, EpiSearch that is based on the Lucene search provider. Lucene is pretty much the standard ‘basic’ search provider for the majority of the big CMS boys, Episerver, Sitecore and Umbraco all have Lucene compatible searches.

With a Lucene index, you can create and define an index via config files and then use an API to add/retrieve items from it. Lucene indexes are stored on disk (which makes load balancing a pain at times) as the indexes are stored on disk this makes it less favorable for a loud hosting approach.

PRO

  • Lucene is widely used
  • More customisable than some other offerings (like Google Site Search)

CON

  • Load balancing needs thinking, having separate indices on each individual node in your cluster can cause
  • Can be a pain to clear out data in the index, due to file locking
  • Cloud hosting need consideration, you wouldn’t have access to the index files

EpiFind

Find is basically an integrated Episerver search provider based on Elasticsearch. Find is cloud based so you don’t need to worry about index files living on a server, re-indexing etc.. so for load balanced environments it’s pretty good. Personally, the bits I like about Find is that faceting (which hurts my head) is done out the box and the API to use it is pretty simple., search results always seem pretty relevant and you can even add weightings to things from the admin panel. Weighted searches always seem like a biggie that’s needed on this project.

PRO

  • Find manages complex things like facets out the box
  • Find can search and index multiple types os content, you can throw a load of C# classes it into, let find do all the searching and ordering and then change your displays based on the object at runtime.
  • Free development index available to try before you buy

CON

  • Find isn’t the cheapest of options. If the website only requires a simple content search, this cost could make it overkill

Elasticsearch

Elasticsearch is the search provider EpiFind uses under the hood, so in theory, if Find can do something you like, using Elasticsearch directly can do the same. I’ve personally never gone down this route so I’m not 100% sure technically everything you would need to do to integrate an Elasticsearch index, but other people companies have created their own bespoke Epi Elastic API’s successfully, so it is definitely possible. Getting a hosted Elastic search is cheaper than Find, but you won’t get Epi’s unified Search and also the automatic content indexing part, so you need to take the extra development costs into account.

PRO

  • Uses the same underlying tech as Find but with less Episerver integration

CON

  • Will take longer to implement
  • No Episerver integration admin screens
  • Needs elastic search skills
  • Have to pay for your own cloud services if required

Google Site Search

Google does what it does. It can index a website and can return content, you don’t have much control over results, ordering, styling. Ordering and different rendering of content are definitely requirements in the FSDs, so not sure if this rules this option out completely. I think if you want a generic search that looks similar to Googles, all you content lives on the website and you don’t care about weighting then this would be the option, not sure in this instance

PRO

  • Quick to integrate
  • Cheap
  • Provides the power of Google to your site quickly

CON

  • Very rigid and can’t be customised that much
  • No custom index filtering
  • Can’t filter on different types of content, all or nothing approach

Solr, Vulcan

Although I’ve had little experience with Solr, I know a few companies use it. Solr is Sitecore’s choice for their advanced search provider and as a lot of agencies work on Episerver and Sitecore projects, companies that are experienced with Solr tend to stick with what they know. When I’m choosing the tech to use on a website, my preference is to pick technologies that are well traveled. Lucene/Google are both great options for simple searching, and Find does a great job for an advanced search. If you decided on Solr then there will definitely be less documentation and support available to you. If you decided to use Solr, you will also run into the same issue of implmenting elastic directly, you will also have to do all the custom development work yourself.

Conclusion

Below lists the main search providers that the majority of websites I’ve worked on in the last 10 years have used. This isn’t a definitive list and there are other alternatives available on the market which might meet your business goals so feel free to explore more. The aim of this post isn’t to provide one recommendation that will work for everyone, the aim is to try and share some of the consideration you should consider before picking an option. If you run an e-commerce site, then having a search that provides relevant results and recommendations will likely mean the company is willing to invest more in the search. If your project is a simple brochureware website, then Google or Episearch will usually suffice.

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

More Posts

5 replies
  1. Dan Matthews
    Dan Matthews says:

    Hey Jon, nice summary. If someone has decided they can’t go the Episerver Find route (which I of course would always recommend) and wants to use Elasticsearch, then there is also the Vulcan option:

    http://world.episerver.com/blogs/Dan-Matthews/Dates/2016/5/vulcan-goes-nuggety-and-gets-a-ui/

    Granted it’s fairly new, but it’s open source and gaining traction. It also integrates with Episerver CMS and Commerce ‘out the box’.

    Love your posts, keep up the good work!

    Reply

Trackbacks & Pingbacks

  1. […] stumbled across this post and your considering using EpiFInd I suggest you read this article, Review Of The Different Search Providers Available To Use On Your Episerver Project. In today’s post, I’ll cover some basic code snippets to query […]

  2. […] my previous tutorial, Review Of The Different Search Providers Available To Use On Your Episerver Project.  I talked about the different search providers available to use with an Episerver project.  If […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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