Good news in the Algoliasphere: we just released a new major version of our Ruby Client. Did you know that the Ruby client was the very first we designed? Version 1.1.3 went out almost seven years ago! It did deserve some new fresh air, to say the least. This new version gets a brand new design and brings you tons of new features, along with being 100% compliant with Common API clients specifications. Let’s dig into this.

Algoliasearch becomes Algolia

The first thing you may notice is that we changed the name of our gem. Our Ruby Client now offers several distinct clients, for the different features of Algolia: Search of course, but also Analytics, Insights, and Recommendation. Because of this change, it only made sense for the gem to reflect the new architecture and to rename it simply “algolia”.

Using the full potential of our whole REST API is now a piece of cake, as you only have to instantiate your client of choice and use the endpoints we tailored for you. They all rely on our retry strategy to offer you the best possible experience (more on this later)

Modern tooling

We used the opportunity of the revamp to use state-of-the art-tooling in the Ruby community. Rake tasks handle the tests and linting. Linting is done with Rubocop, and testing with Minitest. We chose Minitest over Rspec for a simple reason: it was the only one providing the possibility of parallel testing. We wanted to make sure our client was compatible with JRuby so multi-threading is not looked over, and Minitest parallel testing assures us that everything is going smoothly. Also, all methods are documented using the Yard convention.

The minimum supported Ruby version is 2.2. It’s a version still widely used among our users, and it’s the least supported Ruby version in the previous version of Rails, v5. 

Fully independent Retry Strategy

To give you the best Algolis experience and offer you a robust client, we now implement the same Retry Strategy used in all our other clients. It’s the key element to ensure maximum service availability, and because it’s implemented as its separate class, it’s been thoroughly unit tested and works as a system on its own. It also means you can benefit from it in all our different client instances, and even in the event you decide not to use our bundled HTTP Client. Because yes, you’re free to use whatever HTTP client you prefer!

DIY client

This client is easily customizable. The most important things for us when we build our API clients are reliability and Developer eXperience (DX). We want you to be able to use our services with confidence, but also in the way you feel the most comfortable with. In that vein, you can override our requester, you can override our logger, and if you choose to stick with the requester we provide, Faraday, you can also override the adapter you’ll use with it. This is the reason why we chose Faraday as our default HTTP library. Not only was it a joy to implement, but it’s popular and frequently updated, and it answers that need for flexibility we aim to provide you. The default adapter we ship with it is Nett:Http:Persistent, but you can easily switch it for your favorite HTTP library (Excon, HTTPClient, or httpx to name a few). 

Request options

We simplified the way we handle optional parameters. Now, only mandatory parameters are expected in the method signature, and everything else can be passed in the last optional parameter as a hash. If you want to pass headers, timeout, connect_timeout or compression_type, you have to set them explicitly. The rest can be passed as is! It shortens the method signatures and also aligns with our others dynamically typed clients, like Python or PHP.  

Standalone configuration

We’ve added dedicated classes for configuration. This is where you can set timeouts, headers, and specific configuration for each client. Those configurations used to be set directly in the client, but now they have their dedicated class to make them easier to tweak, and separate the logic of each aspect of the clients where it belongs. For example, you can override the default hosts in the search config.

Search Client

The Search Client class has been cleaned up. In addition to handling the configuration separately, we also removed the Protocol class: now you can read the endpoints being hit directly in the main class, and get a better understanding of what’s going on under the hood. Most importantly, it is not a singleton instance anymore: you create your client by passing it your app ID and API key. This instance will run on its requester and pool of connections, and won’t interfere with any other instances running at the same time.

Search Index

The Search Index class remains mostly unchanged. As we mentioned before, the main improvement was to shorten the methods’ signatures by putting all the optional parameters in one single hash. As it was a really appreciated feature, we kept the bang methods to let you wait for the whole operation to finish. You can also do it the way we’re doing in the other clients, by chaining the `wait()` method after your call.

TL;DR

We got rid of the main pain points of the current Ruby client, the Singleton instance of the search client, and the fact that our Ruby Client was not aligned with our common specs. We now have a new base compliant with Algolia standards, with Ruby standards, and following the CTS with extra unit tests. We hope you’ll enjoy using this v2 as much as we enjoyed building it! If you want to get an exhaustive list of all the changes made, please refer to our Upgrade Guide.

Thank you for reading!