At work, we are discussing about two system models:
The goal of the system is to allow clients access information, by browser, served by some remote raspberry-pis that will be connected with different kinds of sensors.
As the pictures show, in the first case there will be a server working as a middleware (Node + Express, for example) to manage clients requests and properly getting/setting information from the sensors (socket communication) they wish to inspect. In the second case, the raspberry-pis will also work as webservers, allowing clients to connect to the sensors they want directly.
So here is what I think: The fisrt case is the default way of how web-systems are generally built. The second case, in my point of view, is a weird way to make this communication process generating a lot of problems.
What I want with this question is to raise some positive and negative aspects from each case.
Here is what I have already raised, please correct me if I said anything wrong.
- Deploy. In the first case is easy to give maintenance/deploy to the middle server code, since there is only one place to do it, in the second case, I would have to change each raspberry-pi in the network. To avoid this hard task, I could create an automatic deploy that would do this for me for each raspberry-pi. Beyond the hard work, there would be any additional problem about doing this?
- Tracking. In the first case, tracking raspberry-pis is easy since as far as they connect, they would fill a list of connected devices, then clients would be able to see which sensor they want to inspect in this list. In the second case, It would be more complex to find all raspberry-pis since there isn't a place to store a list of the connected ones. All the raspberry-pis will have to have a list of all connected devices (a lot of repeated information) and this list always need to be consistent in all devices. Clients need to be able to connect to other raspberry-pis by just connecting to a single one. To avoid CORS in this case, raspberry-pis need to intercommunicate. I don't know whether this intercommunication is nice, but perhaps this can be faster than the centralized server case, since information can be accessed directly: raspbarry-pi to raspberry-pi.
- Speed. Theoretically, direct communication to raspberry-pis in the second case is faster than the first case. But due to hardware limitations, I think the second case can easily overload any raspberry-pi. The application may require data streaming or a faster package sending process.
- Authentication and security. In the second case, that would be a hell. Spread tokens, for examplo, along all raspberry-pis client need to access would be very hard to implement.
(Please tell me if I wasn't clear about anything)