From Request to Axios: A refactoring story

A "love" story between a developer and the code, because "Before software can be reusable it first has to be usable".

Photo by Ivan Henao on Unsplash

Table of Contents

1) The backstory
2) Queue in Axios
3) Finally the code
4) The shamless plug

First some backstory

When it came out, Request was a breeze to use. It made it so simple to perform HTTP requests on Node.js that it was the go-to package for this task. However, Javascript moves quite fast, and there are always continuous improvements. New patterns appear that do not always play well with old code, and sometimes there are too many dependents. This makes radical changes less feasible. Sadly, this was the case for Request, being one of the earliest modules to be created for the Node.js ecosystem. Its destiny was to be relegated to the past!

What did this mean for us at Ziegert-Group Tech?

We were using Request to perform some API calls to some external services. Keeping the code up-to-date is very important, and with it being deprecated, it was high time to find a replacement.

Queue: Axios. A good part of our tech team had previously used it and had good impressions. It is also a very flexible and small package that can be used both in Node.js and in the browser. More importantly, it is promise-based. That means we can use the newer async-await syntax. Some other features also played an important role during the refactoring (more on this later).

Here comes the code

The usage of Request in our code would look similar to this (Typescript with import statements and type omitted):

Here is a list of what we thought was wrong with this code:

1. We are configuring the “client” and preparing the data in the same function. A function should only do one thing!
2. A rather sneaky problem was loading the config multiple times. There were some cases when back-to-back API calls were needed, which meant loading the config more than once!
3. Just in case you skipped the previous sections, Request is deprecated.
4. Awful indentation! Partially our fault and partially because wrapping Request in a Promise makes it possible to hide away the usage of callbacks.

With the list ready, and our big-boy pants on, we were ready to tackle the problems!

Separating the client config from the API calls

First, we wanted to create a function that created the client based on the loaded configs. The challenge was related to how Request handled OAuth1.0a authorization. It’s built-in! That means you can just provide the right configuration object and it takes care of the rest (first gist, line 15).

We used Axios instancing and interceptors. By creating an instance we can specify configs such as the base URL and the content-type header. With interceptors, we can add the authorization header easily.

The getOuathHeader function can be implemented in several different ways. One way is to use the oauth-1.0a package. Using this package, the implementation is quite trivial.

You may rightfully point out that we have not solved the problem with this. The configuration is passed as an argument. That means we would still load it in the body of the function that performs the API call.

Well, that is correct! But we are not done just yet. At this moment, we can use a pattern to solve both points 1 and 2. The singleton pattern!

Making it a singleton

We went with a rather naïve implementation. A class with a getInstance method and a private instance property.

Now we can simply call the getInstance method to get the config and client. The bonus is that we do not load the config multiple times when we perform consequent requests.

Putting it all together

We are sure you are raring to see the result! Here is the refactored API call function:

Finally, we achieved our goals:

1. Client configuration handled separately (in createClient function)
2. The configuration is only loaded once, and the client is only created once
3. Request was replaced with Axios
4. The someApiCall function has much more sensible indentation

More on Ziegert-Group Tech

Thank you for reading this article! Hopefully, this will help to raise awareness of the deprecated state of Request and help developers replace it with a more modern solution.

If you want to know more about what we are doing at Ziegert Group Tech, check out our medium page.

If you are more interested in the business side, you can follow us on Facebook and Instagram.