How to group HTTP requests into a Queue with Angular (2+) Interceptor
Normally in angular applications, there isn’t the need to validate each and every HTTP request that goes through the application unless you really want to. And if you are to validate each incoming and outgoing HTTP request, Angular provides an awesome feature that comes under Angular’s HttpClient: which is the Interceptor. It it very similar to the concept of middleware with a framework like Express, except it is for front-end.
Below is the interface for the HttpInterceptor.
For me to talk about a Queue like implementation for the Interceptor, the use-case that I stumbled upon is as follows.
Filtering out specific HTTP requests at run-time
When the angular application starts, there are limited ways to execute the order of HTTP requests that fire at the application start-time. And though you manage to align the network calls in a particular sequence, there is still room for error, where some HTTP requests may fire before a specific HTTP request of your choice.
As a small example, assume in your application, every HTTP request should contain a specific Request Header (special-http-header: X) in the request, but the HTTP request (HTTP Request A) which provides the response value to the special-http-header is executing with a millisecond delay at the application start-time, where another set of HTTP requests have been fired without the special-http-header: X making the application to crash. (Due to the imaginary fact that the back-end endpoints are configured to accept HTTP requests that only contains the special-http-header: X)
So if that’s the case and you have tried all the magic and couldn’t get the HTTP Request A to be executed first among all HTTP requests, then implementing a Queue based implementation would do the trick for you.
Angular Subject to the Rescue
For my scenario, I managed to tackle it using the Angular HTTP Interceptor alongside using Angular Subjects which resulted a Queue based implementation for the Interceptor. Which resulted the following facts.
- Whenever a HTTP request was fired from the application, a simple validation takes place at the level of the Interceptor which checks whether the current HTTP request contains an unique HTTP Header (access-granting-header).
- If the HTTP request doesn’t contain the above unique header, then the HTTP request is pushed into a HTTPRequest type Array.
- Likewise, until the HTTP Request which contains the access-granting-header arrives, every HTTP request that gets fired before that gets pushed into a request Queue and is put on hold.
- When finally the HTTP request that contains the access-granting-header arrives, the values for the special-http-header: X is retrieved from the HTTP response and the previous request Queue is resolved where each network call is fired again with the special-http-header: X appended to each request Header.
- At last when the special-http-header: X values are finally set, now every HTTP request that gets fired within the application which are lazy loaded, are now fired with the special-http-header: X appended to the request header.
Let's review a code sample to understand what you just read a while ago.
Creating the Interceptor
Lets break down the important parts of the above implementation. First of all we need to have the special HTTP request with a known HTTP header where we can only identify and let the interceptor pass through the specific header bearing HTTP request and continue the rest.
Likewise we can check for each HTTP request at the application start-up, whether if it is the correct HTTP request that needs to be executed first. Else the HTTP request is to be pushed into the HTTP request Queue (array). Once the interceptor receives the correct HTTP request, the HTTP request is executed and the special-http-header: X data values are retrieved from the HTTP Response. Once the response data are gathered, then only the Magic happens.
Once the custom HTTP response is validated, the Interceptor response triggers the Subject stream indicating that the HTTP response queue needs to be resolved. Once the stream is triggered, the Subject stream will iterate through the previously stacked HTTP request queue/ HttpRequest Array and starts resolving each HTTP request with the special-http-header: X header appended to each network call header.
Add the Interceptor to the Providers
QueueInterceptor is the Interceptor class we will be using to include the Queue based mechanism for the HTTP requests which will come under the providers section in the Module class.
Add Mock Service with fake HTTP Calls
As displayed above, the second HTTP request will be the request that should be fired first, but for the uncertainty we will be loading the HTTP requests in a sequence and we will be able to see our interceptor at work.
Once you run the application, you can see that, until the second HTTP request arrives, the previous HTTP requests are stacked in a Queue and once the second HTTP request is resolved, the previously stacked HTTP requests will be resolved. You can get a better idea with the logs below.
If you check the logs, you can see the that there are several HTTP calls that gets fired before the respective Second HTTP Request, and it is the Second HTTP Request that gets executed at first then the rest of the previously fired HTTP calls are resolved from the queue.
For the working prototype and code samples, use the link below.
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
Happy Coding :)