BOLT: Safe by Default and Unified

It’s time for round two of the more thorough presentation of Ucommerce 9. This time the topic includes the two major keywords for Project Bolt, namely Safe by Default and Unified. Also, we have made some big decisions regarding search engines going forward – RavenDB will no longer be shipped out-of-the-box. Instead, we are welcoming Lucene and Elastics. Read along to find out why. 

Written by Søren Spelling Lund, CPO and Founder of Ucommerce

Firstly, if you’re in need of a brief introduction to Project Bolt and our new search-driven API, we recommend that you check out these articles:

Secondly, we’re hosting a webinar about Ucommerce 9 on the 25th of March. Here, we will present and discuss the major news that we are bringing to the platform and organize a live Q&A. Click here to read more about the webinar and to sign up.


Safe by Default

To guide e-commerce developers onto the path of success we designed the search-driven API of Ucommerce 9 to be safe by default to avoid some of the common pitfalls we see in other APIs including our own older APIs.

Simply, safe by default means fast. Regardless of the query performed by BOLT.

The first step to achieve this is to base the API on a search engine like Lucene, Solr or ElasticSearch. Each has its own characteristics, pros, and cons. Regardless, they are fast, very fast.

The second step is to bring the data available through the API as close to the state required in the front-end as possible. The simplest way to achieve this is to flatten the data and perform preprocessing as it is written to the indexes of the API, e.g. a category URL would be generated once and stored right in the index as opposed to being dynamically generated every time it is requested.

Thirdly, to remove the ability to bring back a ton of data implicitly, but rather make it an explicit decision on the part of the developer. 

Imagine that you have a category with ten thousand products in it. There’s no fast way to retrieve all this information in one go. With BOLT, paginating is default and mandatory. Even if you forget to specify page size, the list of products returned will be paginated. It is “safe by default” because unless you explicitly opt out, you’ll get fast queries. 



Developers building e-commerce solutions tend to work in three different functional areas.

Creating web pages, which are semi-static in nature in that they deal with the overall structure of the web site, like browsing a catalog, clicking into a category, or listing products. This particular use case requires a great e-commerce API to handle static queries in an elegant way.

Once a customer starts browsing a category, they may wish to refine the products listed by availability, price, type, size, and more, which requires great support for facets.

Finally, the overall navigation of the website might be initiated by searching for keywords so an e-commerce API must accommodate this as well. 

Thus, a great unified search e-commerce API must cover three key functional areas:

  • Static queries for dealing with navigating the overall structure of the website by clicking through catalogs structures
  • Full-text search to deal with navigation initiated through search
  • Faceted refinement of listings to narrow product listings to those products of interest to the customer.


Search Engine Agnostic

Our decision to create a search engine agnostic API was driven by two key factors to ensure that partners can:

  1. Deploy Ucommerce without having to set up a stand-alone search service or server.
  2. Pick the search engine of their choice even if it’s not supported out of the box with zero modifications required to the web site code.


Zero-touch Deployment with Lucene

Through the years, making it simple to get Ucommerce up and running has been – and continues to be – our guiding principle. Too many platforms require tons of set up to get even a blank page up and running.

Unfortunately, a lot of the available search engine technologies require that a separate service be set up and configured. To avoid this, we decided to ship Lucene as the default provider for the search-driven API. Lucene runs embedded within the solution itself and thus requires zero set-up.

Lucene powers many different search engines and provides a core set of capabilities, which satisfied our requirement for a unified search-driven API as well as zero-touch deployment.


Scalability with ElasticSearch

Scalability in e-commerce is incredibly important to support high-load scenarios like Black Friday. Unfortunately, Lucene as a search technology cannot scale across multiple servers and so we need a second option for BOLT.

In our research, the most prevalent search engine used by partners is ElasticSearch, which supports scaling out by adding servers to a cluster.

To satisfy both the requirement for zero-touch deployment as well as scalability, our search provider model enables partners to seamlessly and transparently move from one search technology to the other if the need arises.

If scalability is not immediately required, enjoy the simplicity and convenience of Lucene, either in production or during development. Should the need arise, simply switch to the ElasticSearch provider without changing any code in the website.


A Word on Availability

To get BOLT into the hands of developers as quickly as possible, BOLT Q1 ships with Lucene as the sole provider. Please note that scaling out using BOLT will not be available in the version available Q1. However, extensibility is built into Q1, making it possible to build your own custom search provider.

Work on the ElasticSearch provider for BOLT will commence immediately upon release of BOLT Q1 and will be made available in Q2’20.


Other Providers

What about Solr, Azure Cognitive Services AKA Azure Search,, and the myriad of other search technologies out there? As of Q1’20 there are no plans to support additional providers beyond Lucene and ElasticSearch.

We do, however, very much welcome feedback. Please let us know if you would like to see support for additional providers.


What about RavenDB?

RavenDB is a great piece of technology, which we still enjoy working with it at Ucommerce. However, feedback from partners indicates that while it is a great technology for some, it frustrates many more. Mostly because maintaining a RavenDB installation is harder than the other more widely used search technologies.

Any existing search infrastructure based on RavenDB will be removed from Ucommerce. RavenDB itself will cease to ship with Ucommerce as of version 9.

If you love RavenDB and wish to continue to leverage it in your solutions it is possible to create a search provider for it to plug it into BOLT.


To learn more about when to expect all of the abovementioned, take a look at our roadmap for the next four quarters:

If you have any questions about querying, Project Bolt, or Ucommerce 9, we encourage you to sign up for our webinar on the 25th of March. Here, you have the opportunity to participate in a live Q&A as well as you can send your questions beforehand, then we’ll do our best to address it. Click here to read more about the webinar and to sign up. 

Product update: Ucommerce 9 & 10

Product update on Ucommerce 9.7 incremental updates, upcoming Ucommerce 10 technical blog posts and the beginning of closed alpha testing.

Infrastructure – Installation – Independence

We present a product update & process overview. The article covers three process parts: Infrastructure, Installation, and Independence. Read the article and follow our progress to Ucommerce 10!
Show more

{{lineitem.VariantName}} - {{lineitem.Quantity}} x {{lineitem.FormattedPrice}} {{lineitem.FormattedPrice}}

Your cart is empty ;(
Total {{basket.FormattedProductsTotal}}