AngularJs API Gateway Calls Multiple Microservices

Question

I am creating an an Angular2 application that will call an API Gateway (Web API) that will call one or multiple microservices (Web API) and it will aggregate the data and return one payload back to the application.

Before I created the API Gateway I just had the Angular2 application call each microservice API endpoint independently within several components. Eg The customer component called /api/customers, the order component called /api/orders etc.

My question is what is the best way for an Angular2 application to call the API Gateway to make one single call to build a page instead of each component making separate calls?

Will I have to make the one api call upfront and store the data somewhere eg localstorage, and then when each component's service requests it's data it will then get it from the storage instead of making the call to the API?

Answer 1

I think there are two scenarios here.

1. The Customer's Component is the parent of the Orders view. In this case, it might be valid to make one big request and pass it on to your orders view. However, just calling the two endpoints in parallel would be faster.

2. The Customer's Component and the Orders view are completely separate. In this case, it isn't beneficial to make one large request. You can make two separate requests upon each page load. If the user doesn't want to see Orders, then it's not useful.

In general, I think it is better to practice if you have two separate requests and call them in parallel. This lets you break your models to be smaller and have better structure.

Hope that helps. Cheers

Answer 2

This one is a bit old, but I want to clarify why having a Big request instead of multiple requests is a better idea...

Some years ago I used the approach driven by jquery patterns that created something like this:

1. Request the page content in json
2. Draw the content using templates, if there's any dropdown or grids then call rest endpoints to request for the options or rows.

The good thing about this pattern is that I can create simple services that can be reused across different pages, allowing developers to extend the functionally easily.

At the beginning this looked like a good idea, it make sense to parallelize the work, as @MangoBoy mentioned in his reply, but the problem with this approach is the limitations of the browsers and javascript, basically there are no parallel work in javascript, there are some streams that are working in parallel, but ultimately the code in javascript is single threaded by design, the end result... if you have 10-20 async elements (like dropdowns) users will see that after rendering the page some dropdowns are still loading, it does not matter how fast your server side works it will happen anyway, hundreds of ajax calls cannot not be executed in parallel as the browser limits to few calls in parallel, I think the number I got was like 10.

One of the many jobs of the API gateway pattern is to aggregate requests and results to avoid exactly this problem. (aka as Chatty requests)

My suggestion to @user1180223 is to create a service in angular an call it in the NgInit or load, and request as much information as possible about the page that might be required by the user as soon as the page is loaded, and then leave async other tabs or elements that will not be required immediately by the user. In the angular class process the result of the ajax call and put them in variables that can be accessed by the components later.

More information about API Gateways here: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

Hope this helps