I have a react application and I am learning React Query.
The application view I am designing is composed of many different parts, it shows lots of different information about a broadcaster.
My main question is im unsure if having many APIs (4) to serve the UI is better than 1 or 2 large APIs. Heres my use case:
A header which shows the name of the channel, its status (live etc) and a meatball menu to perform actions on the broadcaster such as add to favourite etc.
Basic details section about the broadcaster so when their channel was created, when it was last live, how many followers they have etc
A comment log that shows a list of comments people have said about the broadcaster.
Each of the above examples are essentially their own separate scenarios and therefore I plan to create separate components, e.g.
- A header component - uses data from basic details api and meatball actions api
- A metadata component - uses data from basic details api
- Comment log component - uses data from comment api
My idea is that each component would be served by a different API for example:
- Return broadcaster name and its meta data (which would serve data to the header and metadata)
- Return current follower count
- Return current actions available for the meatball menu
- Return the list of comments for a broadcaster
I see a number of advantages of going down the route of separate APIs.
Since I am using react query I can benefit from its cache on data that is fairly static or isn't likely to update often. Such as the metadata of the broadcaster. This could have a longer staleTime compared to the likes of the follower count which I would want to be updating each time and not fetching from the cache.
It also makes my components more composable in that I can re-use them across different views more easily. If the follower count is only querying for its own data, its not expensive to have this in many places.
The disadvantages I see is there will be many http requests to load the screen. Im not entirely sure how best to handle loading states for 4 queries in a nice way from a UX perspective. Id be grateful if anyone has a nice example of this. x4 loading spinners for each request? Or one loading spinner that resolves after all requests are complete. I don't really like the latter because the slower requests will impact the faster requests.
The alternative I see to all of this is to just create a single API that returns all data for the screen. But in my opinion this isn't great because lets say a user performs an action on the meatball menu. If it was a single api, the app would have to refetch all the data again to get the new list of actions and much of the other data it doesn't care about (metadata, followers, comments) for that particular action.
It also means if I want to re-use a component on a different screen thats much harder to do as the component is coupled to that screen and api.
So I guess the over arching question is, in this example or any example where there are many different components that each serve data. And the data in those components needs to update based on actions that can effect it, how would you best go about designing the APIs to serve the UI?