As a Rails and Ruby lover, I often search for the gem that will perfectly cover my use case. When I need to solve a problem I'm having, I want to choose the _right one_, the most suitable solution.

Ruby gems are extensive libraries created inside the Ruby community. The best place to find a ready solution for any task is the website [rubygems.org](https://rubygems.org.cn/), a public repository of gems that can be searched using the search box on the home page. RubyGems’ website is an efficient tool that facilitates the sharing and the installation of packages. But although its search bar is very helpful, I decided to create an [alternative search bar](https://rubygems.meilisearch.com/) more suited to our needs.

![](https://unable-actionable-car.media.strapiapp.com/rubygemsv3_510e7b8445.gif)

The search-as-you-type experience
---------------------------------

First, I wanted to implement a search-as-you-type experience. Which means:

*   a response time lower than 50 milliseconds
*   presenting all matching results immediately under the search box while the user is typing and without them pressing enter

That is not yet the case in the RubyGems' website since a new page is loaded each time a request is made.

The relevancy
-------------

You can get relevant and accurate results by using the RubyGems' search bar, but most of the time only by performing an Advanced Search, which is not always convenient. You have to decide what to fill in the different sections. Are you going to search for a specific package by entering its name (e.g. "devise") or find a package whose summary would match a keyword (e.g. "deployment")?

However, despite this functionality, you may not find gems that meet your needs. For example, if you enter "pagination" you would expect to see the gem "kaminari", which is the most popular gem for pagination among the RoR community, showing up in the results. Here is [the return we get from RubyGem's search bar](https://rubygems.org.cn/search?utf8=%E2%9C%93&query=pagination) when submitting the keyword "pagination". As you can see, "kaminari" doesn’t appear before the 9th result.

Even when [refining the search](https://rubygems.org.cn/search?utf8=%E2%9C%93&query=summary%3A+pagination+description%3A+pagination), the first result to show is "kanimari-core" which is not exactly the more appropriate and famous "kaminari" package we would like to find, but it’s still better than nothing.

Then if we do a search [containing a typo in the request](https://rubygems.org.cn/search?utf8=%E2%9C%93&query=pagintion), like "pagintion", the page is displayed without any result and suggests you a similar word for your next search.

After this experience as a user, I aimed to create **a single search bar able to understand what you want and to instantly find it**!

![](https://unable-actionable-car.media.strapiapp.com/speed_b868b434f8.jpg)

Meilisearch checks all these points, and more!
----------------------------------------------

I've never implemented a search engine; I've never even used one, except a basic Elasticsearch instance with no configuration for a proof of concept. For that reason, all I needed was an easy-to-setup tool, able to handle both speediness and relevancy at the same time. That's why Meilisearch was a perfect fit for this project.

**[Meilisearch](https://github.com/meilisearch/MeiliSearch) is an ultra-relevant and fast search engine**. In other words, it can return the most relevant results of your dataset under 50 ms, and therefore it gives a strong sense of immediacy.

Plus, without the need to configure anything, it handles search miss-spelling: i.e. Typos. Try to submit "devose" instead of "devise" and Meilisearch will return "devise" as the first result.

Finally, **Meilisearch is open-source and integrates a simple [RESTful API](https://meilisearch.org.cn/docs/reference/api/overview)**. You can seamlessly communicate with the API using cURL or [one of Meilisearch's wrappers](https://meilisearch.org.cn/docs/learn/what_is_meilisearch/sdks).

Creating the alternative search bar
-----------------------------------

All the [gems data](https://rubygems.org.cn/pages/data) are available on the RubyGems' website as a PostgreSQL dump file and are updated daily. Thus, I wrote a Ruby script to download the latest dataset, parse the PostgreSQL dump file, and push all the data into my Meilisearch instance. Of course, it uses the [meilisearch-ruby wrapper](https://github.com/meilisearch/meilisearch-ruby) to communicate with the API. This script is hosted in Heroku and runs every day thanks to the Heroku Scheduler.

About the Meilisearch instance, at Meili we manage an internal Kubernetes cluster, which is a handy tool to host demos like this one. For curious readers who would like to find out more, Meilisearch is quite [easy to download and run](https://meilisearch.org.cn/docs/learn/getting_started/installation) by yourself (Homebrew, APT, Docker...).

Regarding HTML and CSS, I kept much of the original structure of the RubyGems' website. My intention was to develop a "search-as-you-type experience" in the same spirit as the original website. The front is deployed using GitHub Pages.

![](https://unable-actionable-car.media.strapiapp.com/chang_duong_F1_UI_4q_Dv1r_Q_unsplash_e212aa22e9.jpg)

Easily improving the relevancy
------------------------------

Without having to set anything up, Meilisearch returns pretty relevant results. Our search engine can quickly find the most suitable packages when inputting gem names like "devise" or "faraday". Unfortunately, for now it’s not always the case with keywords.

Let’s get back to my "pagination" example. If I run the search again without configuring anything, the first result to be displayed by Meilisearch will be the [Pagination](https://rubygems.org.cn/gems/pagination) gem. I don't see [Kaminari](https://rubygems.org.cn/gems/kaminari) at all in the results. That’s because by default, finding a document with a requested word in the title takes precedence over a document with a requested word in the description. Since there are many gems containing "pagination" in their title in the dataset, it explains why Kaminari does not appear at all.

I needed Meilisearch to include the libraries popularity as well. In my dataset, the popularity of the Ruby gems is indicated by the number of downloads. I classified my gems in eight groups of fame (downloaded more than 50M times, more than 30M, and so forth) from `0` to `7`. The latter being considered as the most famous group.

I added this information to every document (i.e. gems) as a field named `fame`. Then, I integrated this rule in Meilisearch settings as a custom ranking rule.

![](https://unable-actionable-car.media.strapiapp.com/5_519da9ed48.png)

Take a look at this snippet above. To put it simply, Meilisearch will execute one by one all of these rules (`_sum_of_typos`, `_number_of_words` ...) and sort your documents following this sequence. When I add my custom rule, i.e. `fame` in `rankingOrder` and `fame: 'dsc'` in `rankingRules`, I'm in fact asking Meilisearch to sort by fame in descendant order.

You might have noticed I have a second custom rule in the example: `total_downloads`, so that my results will be sorted by the number of downloads. But since I chose to place this rule at the end of the list, meaning it was considered less important than the other ones, it will be the last one to be applied. The order of sequence definitely matters.

I'm not going to give further details about the [Meilisearch default ranking rules](https://docs.meilisearch.com/learn/core_concepts/relevancy.html#ranking-rules), even if it’s a particularly interesting topic. Describing how our search engine works deserves indeed a separate article of its own! 😉 _Spoiler alert: Meilisearch uses a bucket sort!_

Now, if you type a [global keyword like "pagination"](https://rubygems.meilisearch.com/?q=pagination) you will find Kaminari in the first place; and if you try again with a [less famous gem name like "pagy" for example](https://rubygems.meilisearch.com/?q=pagy) you will still get the gem you expected! 🎉

Meilisearch + you = 💛
----------------------

These minor settings were really easy to integrate, and your projects might require the same kind of behavior.

Here are some useful links if you want to get ready for your own Meilisearch experience:

*   the [documentation](https://docs.meilisearch.com/)
*   the [Meilisearch's repository](https://github.com/meilisearch/MeiliSearch) on GitHub: support Meili by starring it! ⭐️
*   the [repository of this project](https://github.com/meilisearch/finding-rubygems/)

If you are interested in our project, how it works, or if you have any feedback, do not hesitate to [contact the team](mailto:bonjour@meilisearch.com)! 😁

Meilisearch finds Rubygems

Today, I am about to guide you in the depths of crates.io and how [I made an alternative search bar](https://crates.meilisearch.com) using our instant search engine: [Meilisearch](https://github.com/meilisearch/MeiliDB).

![](https://unable-actionable-car.media.strapiapp.com/crates_io_demo_798a562ddd.gif)

The Meili instant, relevant, and typo-tolerant search engine

[Crates.io](https://crates.io) is the official website that stores Rust community crates (packages), and it's the place where the cargo package manager uploads, updates, and downloads those.

[Sean Griffin](https://twitter.com/sgrif) is part of the crates.io team and maintains the current search engine of it along with the whole website. [Kornel Lesinski](https://kornel.ski/) built [lib.rs](https://crates.org.cn/) an alternative to [crates.io](http://crates.io/) and uses [Tantivy](https://github.com/tantivy-search/tantivy/) to power its search bar. To be honest, I prefer its color design, that's why I took it for our search demo.  
  
I decided to run our instant search engine and test its relevancy overtime against these existing solutions. Our search engine uses completely different algorithms; it is based on prefix search and is typo tolerant.

![](https://unable-actionable-car.media.strapiapp.com/current_results_1_73457862c1.png)

Meili is typo-tolerant and supports a whole lot of other features

So, I asked myself: Why not use our new instant search engine and make it useful to my beloved community? It would give us lots of feedback and probably some pull requests during the process.

* * *

At Meili we manage an internal Kubernetes cluster, this is useful to host demos for clients. The Meilisearch server for this demo currently run on a pod in this cluster.

To make Meilisearch exhibit those crates, we needed to find all the currently available packages on crates.io. Fortunately, this index is available on GitHub in the form of several subfolders with the names and versions of the packages, containing something like _32 000_ files. A commit is done each time a crate is updated to a new version, or a version is yanked.

So, I used the [crates.io-index repository](https://github.com/rust-lang/crates.io-index) to **initialize** our newly created Meili search engine but needed more data first, like, the description, keywords, and categories of each of those crates. Again, the Rust crates.io team was here for us, I talked to [Pietro Albini](https://twitter.com/pietroalbini), and he pointed me to the not rate-limited servers that deliver packages content.

Now that we can retrieve useful data, I create an [async crawler](https://github.com/Kerollmops/meili-crates/blob/67770fe179436eee6478cdebff7d8613f9263049/src/lib.rs) that downloads, extracts, retrieves the Cargo.toml, and upload the essential data to Meilisearch.

![](https://unable-actionable-car.media.strapiapp.com/Screenshot_2019_11_08_Meili_Dashboard_c9d2ae42f1.png)

The Meili dashboard interface showing raw documents

Meilisearch now understands that data and gives us instant, relevant and typo tolerant responses. But, what about new crates? We want to be notified about new crates and be able to send those to Meilisearch.

[Docs.rs](https://docs.rs) is the official website to compute and store the documentation of all the Rust packages hosted by crates.io. It diffs the crates.io index each minute to know about new crates updates. Luckily, it provides an Atom feed of those updates.

It is where [Heroku](https://heroku.com) enters the game. Heroku offers something like _1000_ free hours per month of computing power on their servers and provides us schedulers. We can consume those credits and freely [ask docs.rs about newly updated crates](https://github.com/Kerollmops/meili-crates/blob/67770fe179436eee6478cdebff7d8613f9263049/src/bin/live.rs), every 10 minutes, by fetching the Atom feed, download the updated packages like previously, and finally update our search engine, **live**!

![](https://unable-actionable-car.media.strapiapp.com/heroku_live_timings_1_fbb7661c94.png)

Fetching new crates takes us 4 seconds

Search results were satisfying but not as expected, there was something wrong. When we wrote "serde", for example, the first result was relevant, but the next ones were not. It was related to the fact that Meilisearch did not have enough data to rate crates except the query matching words.

![](https://unable-actionable-car.media.strapiapp.com/Screenshot_2019_11_10_Meili_crates_browser_2000_1_5cfc7e603c.png)

Meilisearch doesn't know how to settle equal crates with only the matching words

**Downloads counts** amazingly improved the search results. [This data is available through crates.io](https://crates.io/data-access). A full database export is done each day, and it contains the number of downloads of each crate. I decided to use those as the last ranking criterion to help Meilisearch settle about crates considered equal.

![](https://unable-actionable-car.media.strapiapp.com/Screenshot_Meili_crates_browser_2000_good_1_21f3eb0098.png)

Meilisearch shows better results thanks to the number of downloads

I deployed a Heroku scheduler to run each day to update all the crates downloads; it takes something like 30 seconds to download the tarball, extract it, read the CSV and upload the _32 000_ crates downloads counts to Meilisearch. So we are far from _1000_ free hours per month.

* * *

I think this search demo is pretty good, but I also thought about adding synonyms and stop-words as Meilisearch supports those. For example, it would be pleasant to write "db" and see results associated with "database". Stop-words would help ignore useless words like "the" or "that" which could pollute search results sometimes, but we need to be careful as crates names could be composed of stop-words.

Meilisearch also supports basic filtering, and it would be great in the future to be able to search for crates in a category or with a specific keyword.

All these improvements can be made by you; [the demo is open source](https://github.com/Kerollmops/meili-crates). The [core engine source code](https://github.com/meilisearch/MeiliDB) is also available on GitHub, that's the whole point of this article! Take a look and talk about it, more people involved, more features!

Meilisearch 最新新闻和公司动态

Meilisearch 发现 Rubygems

使用 Meili 搜索 Rust crates