The front end sends a request to the corresponding backend a, and then the backend an initiates a request to the Internet of things backend b to request data. Is this structure possible?

because the Internet of things backend b has already provided rest api, my project wants to use the rest api interface provided by the Internet of things backend b, but I also hope that some business logic can be managed independently on the backend a.
because my idea is that the front end initiates a request to the background a, the background a does some simple processing, and the background an initiates the request to the Internet of things background b. After the background b processes, the result is returned to the background a, and then to the front end

so is this front-end-background a-background b mode reasonable?
does this approach have some advantages over the front end connecting directly to the Internet of things background b?

if deployed. If background an and background b are placed on the same machine, can the problem of transmission delay be ignored?

Mysql apache spring javascript backend

Mar.11,2021

this method is OK. Just like third-party login, you still need the front end to request the backend api, to request the third-party login interface, and then according to the third-party authorization, the returned user openid is stored in the corresponding user account for association identification, so it is entirely possible to

the front-end connection is OK, of course. This is based on your business logic. If the business logic does not need to process the acquired data, there is no need for the back-end to transfer, otherwise it will need to be transferred in the background

if the network is normal and the execution time is short, the intermediate transmission time can be ignored

Previous: How to add events to imported Obj in three.js?

Next: Under linux, a CPP service, if the CPU and memory is very high, how should it be checked?