Handle HTTP calls in a large scale Vue.js Application

In the previous article, I talked about the project structure i.e. how to organise large scale Vue.js application in the modular and scalable way. In this part of the series, I will be talking about, how should we take care of the architecture, while using the different types of Http calls and which library should be used into the application.

Http calls are the important part of any large scale single page application because it is the way to communicate with the servers to exchange information unless you are dealing with the live data, in that case you might need web sockets instead of HTTP API’s.

Some common challenges arises when we deal with the http calls, such as:

• A common interface, where we can handle all the http calls
• Easy way to manage auth token for each HTTP Api
• Passing the common headers to each api call
• Handling the generic errors such as 503 at a single point for each http call
• Handling the base url in case of different environments
• Handling of multiple base urls in case of large application which will require to exchange data from multiple servers
• Cross browser/platform support

In the modern JavaScript development Fetch API is also very popular nowadays but why I am not choosing it because it still has issues with cross browser support (IE) and other features like Interceptors needs to be developed by the user itself.

There are many features which are out of the box along with Axios such as:

• Cross browser/platform support. You can Axios for browser as well as nodejs environment.
• Intercept requests and responses
• Cancellation of requests
• Promise API support
• Multiple instance of Axios client with different custom configurations

In the last article, I discussed about the folder structure but now, the question is, how can I fit Axios related stuff into that project structure? I think you already got an idea where should I keep this and if you don’t, then don’t worry, I am going to explain that.

I talked about the services. Yes, one that was in module shared and another that was in application shared. As, HTTP client are going to be used throughout the application, so I am going to put it in app/shared/services and the prototype code will look like below:

In the above code snippets, I have added a lot of things and it seems to be complex. Let’s make it simple. I am going to explain each step:

When using Axios, we can pass some common configurations like base urls, headers, params etc. which will be common for all the request done with this Axios instance.

I am creating the instance of Axios by passing the configurations. So, there would be question in your mind, what is the need to create an instance, why am I not using it directly?. Most of the people use the singleton Axios, by just importing and using the Axios directly where they need to call HTTP APIs. There is no major drawback of that approach unless your are working on a large scale application and where you need to provide flexibility, scalability and maintainability. So, the approach, I am suggesting, is to use the exported httpClient from this file instead of Axios directly, whenever you need to call the HTTP Api. The major advantages of this approach will be:

• Your entire application is using http-client interface instead of Axios, so in future if there is a need to remove/change Axios, then it becomes very simple. You just need to integrate another library at a single place.
• Suppose, your application needs to utilize HTTP APIs from 2 different servers with different auth, base-urls etc. Then, it becomes very easy to create and manage a separate instance of http-client for both servers. For eg. server1-http-client and server2-http-client and so on. We can manage the interceptors and configurations into separate files so that we can reuse them within multiple http clients.

In the next step, we are adding some common request and response interceptors like authInterceptor, loggerInterceptor etc. Interceptors provide mechanism to intercept the request or response. This is very similar concepts of middleware in frameworks where we can perform operations like caching, logging, authentication etc.

I prepared the boilerplate around this architecture. You can find it here https://github.com/arunredhu/vuejs_boilerplate. I look forward to see your contribution.

Conclusion:

I am not saying, it is the only way to deal with the challenges that I pointed out. But, it is helping me to deal with these challenges into large scale applications and I hope, it will also help you to get some idea while designing the architecture of your application.