A web app designed with highly modular, small components (in this case using AngularJS directives but could just as easily be WebComponents, ReactJS components, or any other technology). Components often have asynchronous REST API calls, upon initialization or upon user interaction. This design is causing many API calls per page (sometimes 20+). Is there any problem with this design? Some are suggesting we condense the API calls into larger client-side services that act as singletons. So 10 API calls may be reduced to 1, even though a page may only use a portion of that data. Are there any red flags, or problems with this design? Which should be preferred?

  • I think a lot of this is dependent on the latency you experience and the impact that has on the user (do they notice it)?
    – Niall
    Commented Sep 15, 2015 at 13:49
  • These are asynchronous calls and most occur all at once (page initialization). So the user's only see a slightly grayed out screen and a loading bar until all data is loaded. I think it's a good user experience. My only concern is the volume of server calls, is that an issue (API limitations? etc). In a traditional app, I would make a single call to the server per page. Commented Sep 15, 2015 at 13:57
  • 1
    I don't know of any limitations off-hand. It sounds a like a trade off; design vs. maintenance vs. latency vs. etc. I prefer fewer, but that the data is all still relevant to the call (i.e. if data that is required is not relevant to the API call, then make it a separate call). I'll admit, I think this is a 6 of one, half dozen of the other.
    – Niall
    Commented Sep 15, 2015 at 14:05
  • Consider upgrading your server to HTTP 2. Commented Sep 15, 2015 at 16:38

4 Answers 4


This design is causing many API calls per page (sometimes 20+). Is there any problem with this design?

There shouldn't be. The fact that each request is small and async means you can greatly speed up your web app, rather than having to wait for a single large request to complete which blocks everything.

Just make sure your javascript is properly asynconious and can do things while your other requests are waiting and you will end up with a much better app than if you had one massive request that fetched everything.

After all browsers are designed to handle loading of many URLs in tandem, even a typical standard webpage may have tens if not hundreds of requests to images, css, javascript, iframes etc etc


Browsers limit the total number of concurrent requests


So yes, there is a problem with this design. However I think the accepted response is to move to a web-sockets implementation where you use a single connection, but with many message types to communicate with the server

  • 1
    This doesn't seem like a problem as the limit is per browser. So if there's more than 6 calls, the others will just be queued. Agreed that web socket connection would be more efficient, just not sure if necessary. Commented Sep 15, 2015 at 15:31
  • depends on how you are using those calls I guess. The main issue is that as client side code gets more and more complicate you start running into the limitations of javascript. eg. coding a connection pooling socket client in a language designed to change the colour of text on a mouseover
    – Ewan
    Commented Sep 15, 2015 at 15:50
  • "So yes, there is a problem with this design" - that seems like too much of a blanket statement. There are plenty of ways that this design can be implemented successfully.
    – richard
    Commented Jul 8, 2019 at 2:47

Don't forget the size of each network request. Generally, if each request only returns like 2 KB of data, then the network request is to expensive for that small amount of data.

If the network request goes up to 400KB, then break it into two. But generally, not enough data for a single network request is more often the issue.


Some considerations here:


If you are seeing acceptable performance, you shouldn't worry too much about it. If you can manage to run HTTP2 you should see an increase in performance. [1] .


As with any design, there are no hard fast rules as to whether you should do many small requests or few large requests. Some things to consider:

  1. Are many of the calls interdependent? If you have a complex dependency relationship between different calls it can make maintenance harder.If this is the case batching related response data would make sense.

  2. Do different components share much of the same data? If this is the case you could have a central point that does the shared calls and allows components access to the shared data.

  3. Keep an eye on the maintenance burden of the small components doing separate calls. You will know when it becomes hard to manage and then a change may be necessary. Changing a design based on hypothetical future needs can cause design mistakes, because you have to accurately anticipate what problems you will have in the future. If it's working well now, changing it would also be unnecessary.

1: "HTTP/2 is fully multiplexed allowing multiple files and requests to be transferred at the same time, as opposed to HTTP1.x which only accepted one single request / connection at a time. HTTP/2 uses the same connection for transferring different files and requests, avoiding the heavy operation of opening a new connection for every file which needs to be transferred between a client and a server." - https://css-tricks.com/http2-real-world-performance-test-analysis/

Not the answer you're looking for? Browse other questions tagged or ask your own question.