By Arnaud Njoh —

HTTP Request cancellation

In today’s digital age where internet applications and services are flooding the market, ensuring a seamless user experience is crucial. IT applications rely heavily on networking to collect vital information and strong networking support is key for productivity. Therefore for developers, understanding the lifecycle of networking requests is extremely important. Consider Alice and Bob, two typical internet users facing an often-overlooked issue: HTTP request cancellation. This article dives into that concept, describing a powerful tool that simplifies web application usage and boosts efficiency.

Alice: Hey Bob, I don’t like this movie. Can you put the new movie by Antonio Ban… ?

Bob: Ok! Alice, the website is too slow, I cannot navigate through pages.Alice: Maybe it is an internet issue. Let’s call the internet provider.

Alice and Bob during important meetings with investors

Alice: Please, Bob, can you open the page where we can see recent KPIs of sales?

Bob: Yes, sure! Can you remind me of the path to reach this KPI?

Alice: Of course, go to the Dashboard, then click on the blue button with the arrow up icon located in the top-right corner of the page. You should see a pop-up with a list of articles. Select the most recent one then click on the button “visualize” and then …

Bob: Stop, Alice! You are speaking too fast. I cannot follow. I am still in Dashboard and the app seems to be too slow. Probably an internet issue.

Alice: Ok, I am writing to the technical department, so they can take a look.

Context

These two stories have a concealed common point. And NO, it’s not an internet issue. The two web applications are retrieving a heavy set of data when components are attached to the page view and when each component gets unmounted, the fetch actions keep processing by the apps.

Fetching data, and not rendering it or keeping it for future purposes, is not an effortless job for our Web applications. In fact, at this point, it becomes unpleasant for the Browser to process a lot of data, which might be buggy, and ask to force close some tabs or just crash. So it seems meaningless to reclaim a remote resource if we do not need it.

So the question now is, how can we prevent our Web applications from fetching not needed set of data? There are plenty of answers to that question, and we will not be focusing on all of them. One of these solutions caught our attention: Request cancellation.

What is an HTTP Request Cancellation

Looking at the way HTTP protocol is designed, it is almost impossible to break off an emitted HTTP Request; especially on the server side of our Web application. In most cases, when a server is done processing a request, it pushes a response to the emitter or the client; which in turn performs some operations with the obtained data. 

What will the client do if the received data is no longer needed at the time of response? It will still process them even if the data are volatile information. So, the cost will be the use of a CPU and/or any other type of memory.  This probably doesn't mean much for simple and light requests. But it's a different story for the more memory-intensive, heavy calls.

So, the objective of canceling an ongoing HTTP request is therefore to prevent the transmission of the response and its analysis or reading in the client's memory.

How Request Cancellation works?

Request Cancellations are possible using an interface named AbortSignal. 

Signals is an event-driven programming paradigm that enables developers to create custom events and event listeners using JavaScript. This means that they can trigger callbacks or functions when certain events occur within their application, such as user input or data changes. 

The AbortSignal interface represents a signal object that allows you to communicate with a DOM request and abort it if necessary using an AbortController object. 

On the other hand, an AbortController instance is used to terminate Web Requests through the DOM. The controller has a properly named signal, which is a read-only property that returns an AbortSignal object instance and can be used to communicate with/abort a DOM request.

Vanilla implementation of Request Cancellation

const controller = new AbortController();

function doVanillaRequest() async {
  const response = await fetch('/users/kpi', {
    signal: controller.signal
  });
}

// TODO response handler
// cancel the request
controller.abort()

Axios's implementation of Request Cancellation

const controller = new AbortController();

function doAxiosResquest() async {
  const response = await axios.get('/users/kpi', {
    signal: controller.signal
  }); // proceed the response
}

// TODO response handler
// cancel the request
controller.abort()

Conclusion

To sum up, Request Cancellation is a practice that completes the lifecycle of an HTTP request. Among other things, it allows us to decide when a request becomes obsolete for the proper functioning of our web applications. It's also important to know that this pattern may only be used for some requests, as the connection between signals and the DOM is not free, although most current web browsers optimize it.

Bob: Alice, the internet is back! 😄

Alice: Nice! Let’s continue.

Sources

https://axios-http.com/docs/cancellation

https://developer.mozilla.org/en-US/docs/Web/API/AbortController 

https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal