Architecture of app with two independedt interfaces (web, touch screen)

Question

I am going to build raspberry pi based device which reads data from sensor bus (serial port), analyzes it and present it on touch screen. Touch screen will be also used for configuration. Device needs to have web interface with equal functionality.

What I am planing to do is to split application for 2 or 3 separate (python) applications with database as medium for exchanging data. Flask based for web interface and kivy based for touch screen. In order not to choose which one will be "master" that reads sensor bus I am thinking about introducing third one (headless) that is doing main job - getting data, analysing, producing events and storing them into database (MongoDB or MySQL).

Theoretically all frameworks could work in one program in separate threads with common data space, but it seems to be less elastic, and more difficult to maintain and adding another interfaces (e.g. another serial bus to talk to other devices) not mentioning integration with nginx.

Is that right approach?

• lonstar: Not a full answer but consider streams or messages for the sensor data over straight DB inserts. You have a finite amount of threads for persistence so consider decoupling the data collector from the data writer and make it asynchronous.
• d21d3q: @lonstar I am not sure if I am getting it. Isn't DB kind of writer? Ok, reading sensors is the most blocking part, but I don't have much work to do in collecting. After reading one sensor I will check if data is in correct range, and then send it to DB I can make call to DB async, but it won't change much.

Answer 1

You approach is fine is this case, "divide and conquer" in my opinion is the best approach when dealing with different inputs and output.

i would design it like this:

One app to act as an API and the "brains" for the other apps that only collect input.
i would leave the responsibility of displaying information on a web page or/and touch screen with the API app (flask app).

Have the touch screen code at the flask app. and after you done, see if its a good idea separating it. since it will be running under a different thread, the code will be written in a way, that will allow reasonably easy separation later.

the only problem i see is, the Database as a means of communication.

1. all your applications will depend on the database to communicate, it will put a load on the DB, that you will have to take into account.
   also DB locking need to be taken into account, since you may write to the same place from different sources.

2. database will become as a single point of failure - DB down or broken ==> no app.

3. its also harder to scale or distribute you app with a DB dependency.
4. it will persist data that don't need persistence like serial input. after a while your DB will be huge unless you clean it

using a DB as a means to communicate between apps is usually not a good idea. for persistent data of your flask API app you can keep a database, but not for communication.

i see two options for communication between your services/apps

1. just have the agent (serial input) to invoke endpoints at your RESTful API. and in turn it will do its magic, and display the info on web and touch screen

2. message/queue maybe using redis or rabbitmq. like lonstar suggested. but its more complex and maybe overkill for your needs

• d21d3q: I don't need to keep whole history of data, so that I would clean it periodically, and write to DB eg one minute average. I am thinking about using grpc for communication between applications - in that case I won't have any central database, for main app would be enough sqlite. About touchscreen - with kivy I can directly draw on display. With flask I would need to set some browser in fullscreen mode, have x environment etc.
• Urban48: @d21d3q, i still don't see why not start with restful approach, its the most simple way to implement communication today, from there you can improve. grpc is again might be an overkill.
• d21d3q: You are right. Communication between those services can be achieved with restful approach. The only argument standing behind grpc is educational one... I just started making research about ways of displaying on touch screen from flask, that would simplify a lot :) thx!