javascript - Website front-end and back-end separation issues, API writing

The problem of separation of the front and back ends of the website:
For example, the homepage is composed of multiple modules, each module has its own API interface.
The front-end staff asked me to return the data to him at once, and I need to combine the interfaces again.
Is this okay? good? Or is it better to obtain the data separately through multiple requests

Reply content:

The problem of separation of the front and back ends of the website:
For example, the homepage is composed of multiple modules, each module has its own API interface.
The front-end staff asked me to return the data to him at once, and I need to combine the interfaces again.
Is this okay? good? Or is it better to obtain the data separately through multiple requests

Tell me a more serious solution, but it may not answer your question.

According to the concept of big front-end, if a Node layer is added in the middle, server-side rendering can be completed for the front-end and API can be integrated for the back-end. And this is maintained by the front end, without the back end, just do it yourself. :)

When the resource consumption is the same or the resource consumption is relatively small, don’t write two interfaces if one interface can handle it

Node, go and other high-concurrency APIs. It is best not to send it all at once. From a restful API perspective, this is not a good idea. This means that the backend is constantly changing as the frontend changes, and is not suitable for decoupling and modularization. The front end can cache and reduce interactions, such as redux and data caching. Don't go to the backend to get data every time. Even if you give the data once, you can't stop going to the backend to get everything. It's also a lot of interaction. After getting many of them, you can use the cache first, and then go to the server to get the data after a time interval or when the user clicks refresh.

Once, after all, the fewer HTTP requests, the better. Just write a few more lines of code

Different roles have different perspectives on problems.
From the front-end perspective, it may be that all requests are returned, reducing http requests, improving performance, and the front-end can send fewer requests.
From the back-end perspective, the interface is written in modules, which is clear and concise.

I am a back-end person myself. My general opinion is [if I think it’s appropriate, it’s not difficult to develop, it won’t affect you], just merge them together. In the returned data, modules can also be distinguished according to different keys, and they will be added later. ,Deleting modules is also very easy.

Everyone has different roles. There is no need to argue about right or wrong. There are no absolutes. There is no solution that is absolutely suitable for any situation. Please handle it flexibly.

Of course, you can also insist.

If there is a lot of data returned, such as dozens of pages of paginated data, you will definitely need to obtain the data based on paging.

If there is not much data returned and there will be no impact on performance due to the large amount of data returned (that is, the impact is negligible), then it is recommended to return it once, because this may greatly reduce the workload of the front end, and at the same time, because of the request data The times are not very frequent, which is also good for performance.

Don’t you know how to use HTTP 2.0?

HTTP 2.0 multiple requests, once sent, you deserve it.

Also, if the background is RESTful, the combined interface destroys the logic and is very harmful. If the front end doesn't know RESTful, just enable it.

Well, just open a new interface and combine the data of different modules as required. Anyway, different modules are encapsulated, just call them. This interface is also specially used for this purpose, don't mix them.