Is it better to use a single endpoint(One request) to load data from 6-8 tables for a frontend page, or should I follow the separation of concerns principle and use multiple endpoints(Multiple Request), each with its own controller? What are the pros and cons of each approach?
@shadyarbzharothman If you build one endpoint per page, then you’re constantly going to be changing your endpoints as your pages, their designs, and what data they need to display changes. It also prevents your endpoints from being re-usable since they’re tightly coupled to what your web page designs require.
@martinbean Thanks!
I would say it depends.
If you have like a view that displays some kind of list and uses multiple tables joined, then I would make that a database view.
I would do the same with a page that uses unions to show the latest from multiple queries.
If it is a page that contains total different entities of data like, opening hours, news, sales, or such, then one endpoint for each entity
@Tray2 In my case I have 6-8 table data that need to be load to the page before doing anything so I'll do the same as you said last thing, thanks!
The point of the controller is to handle the request and orchestrate all the data required in the response.
Save separate endpoints for dynamic data that needs to change through user input
@Snapey Thanks!
Please or to participate in this conversation.