Enhancing Readability and Maintainability of Multiple API Calls in Angular

I have been rewriting some of my Angular apps recently to adhere to the new v17 syntax. While working on that, I noticed some of the uglier code patterns I had been using and took a chance to follow up and improve on them. One of those patterns: fetching data with multiple API calls for a unified rendering on a single page.

What’s so special about making multiple API calls?

Sounds simple enough. Call API 1, 2, 3, render results, and move on. How hard can it be? Well, it’s the issue of properly showing loading indicators, handling errors, and making sure you are not overwhelming the server with parallel calls. Let me talk about a specific scenario to illustrate this better.

I have a trading app that helps me monitor my stock positions. In this app, I have a daily reports page where I run three different reports generated by the backend:

• A position report showing me all the “interesting” things that happened to my stock positions and any positive or negative rules any of the positions might have triggered
• A daily report on the tickers for each position that shows interesting things that happened price/volume wise for a ticker that represents my position
• A weekly report on the same tickers that basically do the same thing as the above item but on a weekly price bars

Each of those can be costly/error prone, and slow to run as I have to ping a brokerage endpoints on the backend and run some rules on the results before I have the data I want to render.

Here is how the report looks once it’s run. I will highlight the areas that are three different reports:

It’s perhaps not the best looking thing and is choke-full of information, but it’s not geared for a new user and is strictly for my daily reviews, and I am very familiar with what’s going on there.

Behind the scenes implementation

All the data for the report is obtained by making essentially three API calls chained together. Setting the property value kicks off the chain of calls:

It’s decent, but the ugly thing in there is the call chain that the reader needs to be aware of to figure out how the data is being fetched. Setting the “dailyAnalysis” property calls loadPositionData() which then calls loadDailyData() which then calls loadWeeklyData(). If for some reason I need to change the order of the reports being generated, or add a new one, I have to follow the chain and re-chain things. It’s a process that’s error prone and harder to follow. Trust me, this page went through a few iterations, and many times I would forget to chain things properly.

There is also duplication involved in making sure that the chain is not broken from one report to the next when errors occur. And those errors do occur from time to time, mostly due to brokerage availability and throttling.

You can’t tell from the code right away how many APIs will be called until you follow the chain along. Ugly ugly. I knew I could do better, and I think I have settled on a pattern I like.

Improved version with concat

This is what I have ended up with as my latest iteration:

I declare each observable that’s involved in fetching the report and use concat to subscribe and fetch results. Each observable looks the same, there is map for dealing with the results, error handling, and finalize call to stop progress indicator.

My most favorite change here is that I can tell right away how many service calls I will make to get the data I want. If I decide to change the order, easy peasy, just shuffle the items in the concat call. If I decide to add some other report call, it’s clear where to do it, and I don’t have to follow any chains along anymore. There is no duplication needed to continue the chain for success and error states.

I am pretty happy with this pattern and will stick with it until something better shows up.