Vulcan comes of age

Vulcan, the lightweight ElasticSearch client for Episerver, has been around for almost a year and is being used on various projects in all sorts of places – the US, South Africa, Scandinavia. It’s been surprisingly stable (considering I wrote the core codebase) and we’ve been able to add some quite cool features – like a simple UI , Commerce support and a POCO indexer. The project has also been driven forward massively by Brad McDavid from Episerver partner WSOL, who has been an absolute legend in adding new features as well as bug fixing, helping with deployments and generally being an all-round top geezer. Coming into 2017, we need to bring Vulcan up to speed with latest developments, and so we’ve released a new version of Vulcan in the Episerver Nuget feed with the following features:

• Support (in fact, a requirement) for Epi 10
• Support for controlling what gets indexed
• Support for automatically re-indexing Commerce variants on price change
• Some bug fixes

In addition, we’ve moved the codebase from GitLab to GitHub, simply because it seems to be more familiar and provides plenty of third party tools/integrations. If you want to use Vulcan with Episerver 9 or earlier, we suggest forking from the old GitLab repo and fixing up / working with that as you need to – we aren’t intending to actively do anything to the older codebase from this point on as Epi 10 did introduce breaking changes that we needed to pick up too.

In code terms, there’s been a few improvements and tweaks, but the most significant in the core is the ability to exclude content from being indexed. This is better than using filters if there is something you really don’t want to even index – for security, simplicity, compactness or any other reason. To do that, simply give the Vulcan Handler an instruction on how to handle a particular content type. By default, everything is indexed, but if you specify a content type to the handler, you can control whether content of that type should be indexed. It does support inheritance, so at the simplest level you could specify IContent and restrict that somehow! In reality you’re more likely to want to handle specific types. The instruction itself is a simple lambda expression - here is an example of restricting certain products in a commerce site from being indexed if they have specific parents:

VulcanHandler.Service.AddConditionalContentIndexInstruction<GeneralVariation>(v => !excludeReferences.Contains(v.ParentLink.ToReferenceWithoutVersion()));

Normally you’d probably put this in an Initialization Module so that it starts up with the website. In this case, I’m using property injection for the Vulcan Handler but you can use another choice if you think that is an anti-pattern.

Where to from here? We want to move to the latest version of the Elasticsearch .Net library and API (NEST). This will probably be the next major Vulcan release. Other than that, we’re always on the lookout for things that would make Vulcan even better… features or enhancements. And while we’re on the subject, we’re always on the lookout for people to contribute more features / bug-fix / clean-up / enhance this module as well. It’s become very apparent that there’s a gap between DIY Lucene and full Episerver Find where Vulcan is ideal. If you want to use it, consider contributing to make it even more awesome for everyone!

DISCLAIMER: This project is in no way connected with or endorsed by Episerver. It is being created under the auspices of a South African company and is entirely separate to what I do as an Episerver employee.