One of the main interactions in ReciPal's nutrition label maker is creating a recipe, which means searching for ingredients and adding them as part of your recipe. Part of that is the autocomplete feature helping you out as you type, and part of that is the actual search when you hit the "Search" button.

Speed and Consistency

In a nutshell, those two parts of search (autocomplete and actual search) used to be based on different methods (and thus gave you different results), and the actual search was a little slow. Now they are based on the same search method, give you the same results, and load much faster. Overall, a much better experience and easier to find what you want. We added some goodies like search filters as well. And we'll get a little nerdy if you're curious how it all happened. Read on :)

Edit (2/24/2016): One of the good things about the old autocomplete was that it completed partial searches as you typed. The new search didn't do that initially, but now it does autocomplete partial searches - plus it conducts the regular search with partial matches :)

Autocomplete results include the ingredient key and are the same as actual search results!

A Faster, More Reliable Search

Initially our database was relatively small and it made sense to use a simplified search database. It worked, was simple to implement, but it didn't really scale with all the ingredients added to the database over time. It also was never fast enough to be used for the autocomplete part of the search, so we were always using a separate method for that. And because of that there was a disconnect between the autocomplete results and the actual search results.

So, we finally switched over to using a search specific database that is really fast, more reliable, and allows us to use the same results for the autocomplete. So you won't see one thing as you type and another thing when you actually search. Or have to wait more than half a second when you search. And you see in the autocomplete results if the ingredient is verified or not too. All big wins for you when you use ReciPal.

Advanced Search and Filtering

The other benefit of offloading search to a search database was that it became much easier to filter along certain elements. For that reason, we now have "Advanced Search", which lets you filter search results by different criteria like the USDA database, verified ingredients, non-food ingredients, and ingredients that you've either created yourself, or ingredients that you've previously used. That makes it easier to restrict your search results and maintain consistency and quality of the ingredients you have in your recipes. Once you have a few recipes, you might want to only use ingredients you've already used - you can be sure of that by restricting results to "My Recipe Ingredients".

Filter ingredients by verification status or ingredients you've already used.

Getting Nerdy With Databases

What we did initially was use the internal full text search available in Postgres. It was easy, required no additional libraries, servers, syncing, and just works. But, it's not optimized for search or the customized results ranking that we do, and it can be slow as the document database you're searching against grows.

For that reason we used the original Bootstrap client side library for autocomplete search rather than Postgres, so the autocomplete and actual database search was different. Plus, loading each page with the data for the autocomplete was slow, although autocomplete itself was very fast, since it was client side (and rather simple).

We still Postgres full text search for our blog, and it's lightning fast for that, but that's because it's only hundreds of records rather than tens of thousands, and we don't do any custom ranking for it.

So, what did we do? We switched to a search server. There are lots of open source options out there, but we settled on ElasticSearch. It sits on its own server, syncs against our ingredient database, and is optimized and indexed to search exactly what you need. It took a little tweaking to get the search results in line with the original Postgres results, but it's pretty similar and just much, much better. The response times are generally <100ms, and because of that you can use it to populate the autocomplete results too, whereas Postgres was just too slow to use for autocomplete.

Parting Words

What do you think of the new search? Did you even notice? Hopefully you noticed it's a lot faster :) We think it makes our nutrition label maker better without any drawbacks for customers, but let us know in the comments.