Search templates is a brand new feature  added to elasticsearch version 1.1. 0. It allows potentially complex search logic to be stored as templates. The user sends a query with the parameters that matters for him, along with the name of a search template, and the supplied parameters will be inserted at the proper place on execution.  The template format is moustache, a widely used javascript templating tool.

Cool stuff, you say. How can I use it? And does it really work?

In the current implentation of search templates, you create a JSON request specifying both the template and the parameters.

You can save the templates in the config/scripts folder of your elasticsearch installation, and use the saved query.
The template is saved as config/scripts/ingredientsquery.moustache. This is how my template looked like:

And here is a sample query using this template

To make changes to the template effective, you need to restart elasticsearch.

You would perhaps expect it to be possible to upload a search template using the REST API.  Unfortunately,  that hasn’t been implemented yet.  At the moment, you have to store the search templates in the  config/scripts folder in your elasticsearch node.  There is an issue registered to add this feature, but in the mean time, our friends over at qbox are helpful as always and offer to manually place the templates where they belong while we wait for elasticsearch version 1.1.1 (or something).

Using this awesome feature, the only reason we still need some middleware between our elasticsearch installation and our browser is to protect the search service from malicious requests. As it so happens, Qbox have recently added a feature that enables public read only access to the elasticsearch query _search endpoint.

This enables us to use the Qbox elasticsearch service directly from the angularjs client for elasticsearch.

Thus we eliminate the need for the searchclient in ruby, and one less server component to care about.

Sounds nice? This is work in progress, so check back every now and then for new blog posts.

1. Learn more about search, both tech and UX.
2. Show that a nice search user experience doesn’t need a search input box.
3. Show a search that is light weight.
4. Generally, build something nice, quickly, to show off.

“But what is it?” you ask again. The second answer is that it’s a search application for recipes containing the most in-season vegetables, fruits, mushrooms, fish, shellfish, poultry and meat. So, a search without a search box giving you the recipes that will make you pick the freshest, most tasty food available at any given time of the year. In Norway, you can get strawberries the whole year around, but it’s only a month or two during the summer that they taste really good. and are cheap. This goes for a lot of different foods.

We’ll blog every step of the journey. First small hackathon is this Friday, January 7th. To test our ideas we’ve already crawled food recipes from Klikk.no, and transformed them into JSON-format by using Forage Document Processor from Fergus McDowell’s excellent Forage Search Engine.

Next step is to get an Amazon EC2-server up and running, install Elasticsearch, and feed it recipes in JSON-format. We’ll also make some rough mockups of how the user interface is going to be, and maybe, hopefully get a simple version of the Seasonal Food Recipe Web Application up and running. If we after a while get enough traffic, we’ll try to do some machine learning. And we’ll definitely test out different ways of doing relevancy tuning.

Sounds nice? This is work in progress, so check back every now and then for new blog posts.