Architectural advice ... DB, Server, REST Api and Qt Apps

[Heinz]

Dear Qt Folks,

here comes a pretty general question. I hope you can push me into the right direction as I want to solve as many parts as possible using Qt.

I would like to collect data from different devices in one central location and access it from everywhere. To work with the data I already have lots of qt Code Snippets that are working locally or with manually delivered data. The task is to put all of them together to a safe and stable bigger system.

What are your suggestions or opinions on this setup:

• Internet server with Windows
• Installing a DBMS like MySQL or MSSQL
• No direct access to the database from outside for safety reasons
• Instead writing an API that runs on the server and allows indirect DB Access via predefined (HTTP?) Requests
• Sending Data from different Qt Apps to the database using the mentioned API
• Reading the data using the API and visualizing it in a Qt App (and maybe a website in the future)

The part id have to do next would be to define and write the API using Qt, which could lead to some further questions, but I dont want to start in a wrong or overcomplex way...

Therefore the question: Would you run a setup like this or is there anything that could be added or changed to improve security, stability or complexity?

Thanks for all helpful thoughts!!

[JonB]

@Heinz
Seems pretty good start to me :)
Unless you are specifically Windows, why Windows server instead of Linux?

[mrjj]

Hi
Just as a note.
Did you consider using an IOT service like
https://thingsboard.io/
It offers so much out of the box, even the open version.

[Heinz]

Thanks for the great feedback!

@JonB said in Architectural advice ... DB, Server, REST Api and Qt Apps:

Unless you are specifically Windows, why Windows server instead of Linux?

-> Its really just for convenience reasons, as I am not used to working with Linux. But I hear you!

@mrjj said in Architectural advice ... DB, Server, REST Api and Qt Apps:

Did you consider using an IOT service like
https://thingsboard.io/
It offers so much out of the box, even the open version.

-> Now thats an incredible and really complete toolbox there. Thank you for the hint. I am trying to realise my project more or less for the fun of it but its great to have a fall back that I could come back to.

Can you give me an advice on how to work around authentication between client and API? I am thinking about storing the username and a hashcode of the password in the database. Then the client would have to include both in every request in order to get an answer. Or are there better ways?

[SGaist]

Hi,

@Heinz said in Architectural advice ... DB, Server, REST Api and Qt Apps:

Can you give me an advice on how to work around authentication between client and API? I am thinking about storing the username and a hashcode of the password in the database. Then the client would have to include both in every request in order to get an answer. Or are there better ways?

Work around authentication ? I hope this was an unfortunate choice of words ;-)

Even if for a fun side project, I would recommend taking good habits from the start. Server side, you could use Django which already provides a pretty nice user support out of the box with secure storage of the password. As for the API access, a pretty common pattern is to use a token returned upon authentication and that you use when sending a request. That token can have a certain lifespan so that if for example no calls have been done it the last hour, it will require your user to identify again before continuing. If you go the Django way, you also have the Django REST Framework to easily build such services.

Note that if you would like to stay with Qt, there's the Cutelyst project that might be of interest.

[kshegunov]

@SGaist said in Architectural advice ... DB, Server, REST Api and Qt Apps:

As for the API access, a pretty common pattern is to use a token returned upon authentication and that you use when sending a request. That token can have a certain lifespan so that if for example no calls have been done it the last hour, it will require your user to identify again before continuing.

Yes, and to add a thought here:
Usually that token, beside having a lifespan when not used, is also single-use. That is, on each reply one gets, one also gets a new (regenerated) token for the next request one may want to issue.

[Charby]

Regarding your stack :

• Internet server with Windows : I really think Windows really have no added value in this area.
• Installing a DBMS like MySQL or MSSQL : you might be interested in NoSQL kind of database as you probably have limited relations between your data. I think some database also integrate out of the shelves a Rest or Curl API, at least that used to be the case with couchDb for instance
• No direct access to the database from outside for safety reasons Instead writing an API that runs on the server and allows indirect DB Access via predefined (HTTP?) Requests. if possible, aim for HTTPS right from the start.

Regarding the authentification, for a pet project I have been relying on Wordpress to manage user management through REST, I am not sure tough it is actually a good solution but at least it is cheap and quite easy to set up.