hiyaryan
commented
2 years ago @ezio-melotti Looks good! So we want the live backend to plug in to the docker-compose in the same way the frontend plugs into it. Essentially the "docker-compose" container will be responsible for managing the network, database, and sim version of simoc. That means we'll need to spin up three different containers, simoc-web, simoc-sam, and simoc for live mode?
We also have at least two different scenarios we want to cover:
- Regular users using the live mode from ngs.simoc.space;
- People living inside SAM and/or mission control
I was wondering maybe this would be three different scenarios:
- Regular users using the live mode from ngs.simoc.space;
- People living inside SAM
- Mission control
Each would have access to different parts of simoc, have different privileges, and access sam differently. Or maybe the pairing should be:
- Regular users using the live mode from ngs.simoc.space and/or Mission control
- People living inside SAM
We might also want to support a standalone installation. In that case we could reuse the same socketio container and use docker-compose to bundle it with e.g. the nginx and MySQL containers...
If you do want a standalone installation maybe we should work on building this first. It'll be easier to test everything on this setup. Once this is built, maybe we can find a way to plug it in to the existing backend and use this container as the socketio backend container in your first diagram.
ezio-melotti
This issue discusses proposes a possible architecture for the Docker containers setup and communication between the frontend and backend(s) in different scenarios.
The simplest architecture is to add a new standalone socketio container that can be plugged to the existing backend, in the same way the dev frontend does. Both the dev frontend and the socketio backend have their own repo, their own container, and just connect to the current backend without using docker-compose:
Ideally this new socketio container would be standalone, meaning that it will launch a socketio server that will wait for connections without having to rely on the other containers to functions (similarly to how you can start the dev frontend without the other containers). The actual clients connecting to it could then be the regular frontend (which lives in the
Flaskcontainer), the dev frontend (which has its own standalone container), a standalone Python script, a CLI tool, etc.:(Both the dev frontend and a standalone Python script could connect to the socketio container and request the data. The socketio container won't know nor discriminate and send data to whoever requests them.)
We also have at least two different scenarios we want to cover:
I think that for both these scenarios, we can spin up both backends, with the regular backend serving the frontend, dealing with user login, and possibly with simulations/prediction, and the sam backend sending live data whenever the user selects the live mode from the main menu.
So the sequence diagram for a user opening the frontend, logging in, selecting the live mode, and disconnecting will look like:
(Note: the diagram is not meant to be an accurate representation of all the steps, but just outline the general idea. When the user selects the live mode, the frontend will connect to the sam backend via socketio. After the frontend requests sensor data, the sam backend will keep pushing data until to the frontend until it disconnects.)
We might also want to support a standalone installation. In that case we could reuse the same socketio container and use docker-compose to bundle it with e.g. the nginx and MySQL containers:
This could be accessed directly, or if the SIMOC frontend is needed it could be added too and served statically (with the login and simulation mode disabled, since those require the regular backend). The sequence diagram will then look like:
This architecture doesn't discuss how the socketio container obtains the sensor data. It could read them from a DB or Redis (that could be in the same container, in a new separate container, or in the same MySQL DB/Redis used by the regular backend). The process that actually reads data from the sensor might also be part of the same container, or a separate container/repo, or even standalone scripts that don't use Docker.