Architecture application web / serveur / bidules connectés

Bonjour les agrumes !

Je redébarque dans le web après des années sans trop coder et je suis un peu paumé. (J’ai décroché en 2010 quand Node.js commençait à être un peu ’hip’.) J’ai pour projet de faire une petite application pour quelques utilisateurs mais j’ai l’impression de me perdre un peu dans la masse des possibilités.

Pour faire simple, cette application doit afficher des données récupérées via des capteurs, eux-même connectés à internet.

Mes contraintes sont les suivantes :

• l’application doit être utilisable principalement sur smartphone (iOS, Android principalement)
• l’application doit pouvoir gérer une cinquantaine d’utilisateurs, chacun avec ses propres données/capteurs
• j’aime bien la sécurité (j’ai trainé sur divers challenges depuis 2010, donc je ne suis pas trop en dehors du ’game’ de ce côté)

Je me balade sur le net depuis quelques jours pour choisir les technos/frameworks/… à utiliser et je suis toujours preneur de trucs et astuces. Avant de me lancer dans le code, j’essaye de trouver une bonne architecture pour connecter tous ces trucs.

Pour le moment je pense à faire une Progressive Web App (PWA) avec une seule page en utilisant :

• React / Material Components / un Service Worker et bundle avec webpack pour le frontend
• expressjs pour le backend, mais je pense qu’il va me falloir un mongoDB ou quelque chose d’autre pour gérer les bases de données, sessions, …

J’ai surtout un soucis d’organisation des liens entre ces pièces. En gros, mes capteurs doivent communiquer avec mon serveur avec une API REST. Je dois ensuite transférer ces données pour les afficher sur ma PWA.

Mes principales interrogations sont, en vrac :

• un seul serveur pour backend de la PWA et communiquer avec les capteurs VS un serveur pour servir les pages web et un autre pour la communication
• pour mon application avec une seule page, il vaut mieux avoir une page séparée pour le login/mdp ?
• sûrement d’autres choses qui vont me revenir…

Bref, si vous avez des suggestions sur un peu n’importe lequel des points ci-dessus, je suis preneur !

Merci d’avance !

TL;DR: Help me, I am paumé.

Merci pour vos réponses.

Un protocole émergeant gagnant en popularité qui répond bien à ce besoin est MQTT, c’est moins répandu que des architectures REST (c’est plus spécifique) et donc c’est plus compliqué de trouver de la documentation mais je pense qu’il serait mieux adapté à ton cas qui m’a l’air d’être exactement ce pourquoi il a été conçu.

Bonne idée, je n’ai pas trop regardé ce côté là. Il faut que je regarde de plus près parce que je ne construit qu’une partie des capteurs, la partie connexion à Internet étant gérée par une pièce extérieure.

Je suis plus la logique de la programmation modulaire, du coup, de mon point de vue, je te dirais de faire un serveur pour ton app web et un pour tes capteurs. Mais tu peux très bien mettre les deux sur le même serveur physique (pas besoin de prendre 2 dédiées).

Je viens de me rendre compte d’un problème avec cette approche : je dois faire communiquer mon serveur web et mon serveur des capteurs/données pour afficher les données de l’utilisateur. C’est une connexion de plus qui doit se faire seulement entre mes serveurs mais elle ouvre des accès en plus à sécuriser (interface serveur web <-> serveur de données, pour faire une sorte de GET données_utilisateurs). Je me demande si ça vaut le coup d’ouvrir une porte de plus (bon après, je ne pars pas sur un modèle de menace à haut risque, c’est plus par principe).

Les goûts, les couleurs… ça ce discute. Mais la tendance est plus à tout mettre sur la même page. En plus avec React tu peux faire un composent destiné uniquement à l’authentification.

Mon idée derrière la question était plutôt de sécuriser le truc plus simplement (un dossier de fichiers html/css/… accessible à tous et un autre étant l’application accessible aux utilisateurs connectés), et d’optimiser le chargement (éviter de balancer des fichiers inutiles sur la page de login, mais ça doit pouvoir se changer facilement ça). Je viens de regarder Gmail/Facebook et ils chargent une nouvelle page.

Je n’ai pas compris pourquoi tu as besoin des données de l’utilisateur sur le serveur des capteurs. Tu pourrais ré-expliqué s’il te plait ? Car là, je ne voie pas où tu ouvre un nouvel accès.

Pardon, je me suis peut être embrouillé dans mes explications (et/ou alors, j’imagine un truc trop tarabiscoté).

En gros :

• J’ai mon/mes serveurs au milieu.
• D’un côté, les capteurs envoient des données au serveur. Les capteurs appartiennent aux utilisateurs, un utilisateur ne doit pas pouvoir voir les données des autres.
• De l’autre côté, ma page web doit afficher les stats/graphiques/données de l’utilisateur connecté.

Mon idée actuelle des deux serveurs (que je crois comprendre, qui est peut être mauvaise) est la suivante :

• Un utilisateur se connecte et demande (GET) les données, disons la température pour fixer les choses.
• Le serveur web (backend) reçoit la requête, demande la température des capteurs de l’utilisateur à l’autre serveur (ici j’ai le fameux accès).
• L’autre serveur lui transmet la température demandée.
• Le serveur web render la page et répond à la requête de l’utilisateur.

Avec ce modèle, mon serveur des capteurs doit avoir deux accès :

• Un premier pour communiquer avec tous capteurs.
• Un autre pour communiquer exclusivement avec le serveur web.

Pourquoi tu centralises les données si chaque utilisateur ne peut accéder qu’aux données de son propre capteur ?

EDIT pour le message d’avant : Je viens de me rendre compte que j’avais une BDD, pas besoin de passer par ces connexions superflues.

C’est à dire que chaque utilisateur fasse tourner son propre serveur ?

Ah non j’ai fais le raccourcis 1 utilisateur = 1 capteur
donc c’est pour agréger plusieurs capteurs sur un même rapport

Et tes capteurs peuvent communiquer directement par requête SQL à la BDD ?

Et tes capteurs peuvent communiquer directement par requête SQL à la BDD ?

Pas vraiment, mais j’avais prévu de coder ce fameux "serveur des capteurs" pour faire le lien entre eux et la BDD (ça va dépendre du protocole, mais si c’est de l’API REST, je vais juste faire le lien entre leurs requêtes POST et la BDD).

Tu ne garde pas les valeurs précédentes de tes capteurs ? Les X^ième précédentes + la dernière valeur enregistré. Ou tu update toujours la même valeurs (une valeur par capteur) ?

Je garde toutes les valeurs. Le but c’est aussi de regarder des graphiques (sur l’interface de l’utilisateur).

Il me semble qu’il y a moyen de faire une « base de données réactive » avec MongoDB en utilisant Meteor, genre il détecte tous seul qu’il y a eux des changement et du coup si tu as bien codé ta vue, elle ce met à jour toutes seul car Meteor aura informé le client des données qui on changé.

Et tu peux géré le fait qu’un utilisateur à accès qu’a certains capteurs avec une BDD Mongo et Meteor, il repose sur un pattern Publish–subscribe qui permet donc ceci.

Après peut-être que @leroivi à une solution tout aussi valable avec d’autre techno et BDD (SQL notamment) ?

Pas du tout x)
Moi je viens de l’embarqué, donc il m’arrive de venir utiliser ou fabriquer des "bidules connectés" mais coté serveur j’ai pas encore eu l’occasion de toucher
donc j’essaie juste de faire avancer la discussion avec ma petite culture