microservices - REST API for UI - One General Endpoint vs Endpoint per Component

Question

Let’s assume we have two micro-services: companies API and accounts API.
We also have a dashboard that displays some data and visualizations about accounts.

The dashboard includes three widgets (for simplification):

Widget 1 - A table of accounts filtered by some criteria, for example, shows only pending accounts. It also displays a few columns related to the account's company properties.

Widget 2 - A piechart that displays a breakdown of accounts by one of the account’s properties.

Widget 3 - Another chart that shows a breakdown of the accounts by a company.

Theoretically, all of the widgets in the dashboard display data about the same entity - accounts.
Now, I would like to ask about two approaches for fetching and displaying the accounts in the UI:

The general REST endpoint approach

• Create one general endpoint for fetching accounts.
• Create one general endpoint for fetching companies.
• Fetch all of the accounts once the user enters the page.
• Fetch all of the companies once the user enters the page.
• Let each widget manipulate, filter, and join data based on its needs.
• Most of the logic lies in the frontend.

The REST endpoint per widget approach

• Create an endpoint per widget that returns all the relevant data for a specific widget, already filtered, manipulated, and joined for the widget needs.
• Each widget calls its endpoint and displays the data.
• Most of the logic lies in the backend.

My questions are:

• What are the pros and cons of each approach?
• In which case would you choose one way over the other?
• Are there any other ideas for addressing this use case?

question from:https://stackoverflow.com/questions/65645913/rest-api-for-ui-one-general-endpoint-vs-endpoint-per-component

Answer 1

Here are my ideas around this:

• If you create one general endpoint per entity, then the frontend workload depends on the amount of data you get from the backend (number of accounts / companies). If you have a limit on those entities (say like max 10 accounts), then it shouldn't be an issue. If not, then it might be problematic (over time) to go on that path.
• One scenario where I would consider one endpoint per entity is if you have other components (more important) which are consuming data from this REST API, and they need to get data in this way. But even so, I would think twice if this is really necessary.
• AFAIK, the best practice around UI data flows is that you should do as much work as you can on the backend, where you have control on the resources and you have room for optimizations.
• One idea that you can consider is to think about a way to store the data more efficiently (already prepared for the view), to minimize the backend work.