Architecture application web / serveur / bidules connectés

Organiser le bazar avant de le coder

a marqué ce sujet comme résolu.
Auteur du sujet

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é.

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut Kanaal,

Et bon retour dans l’horrible magnifique monde du web :)

L’idée d’un site single page pour ton projet est bien pensée je trouve.

Les technos que tu souhaites utiliser sont pas mal (tu viens de me faire découvrir « Material Components » d’ailleurs ^^). Après personnellement, je n’ai pas choisi React car lorsque j’ai voulu l’apprendre, j’ai vu que ça semblait une belle usine à gaz (et je passe sur le fait que c’est maintenu par Facebook, donc si tu veux te Dé-GAFAMisé, c’est pas ça qu’il faut utiliser ^^). Personnelement, j’utilise Vue (enfin… Nuxt). Mais les deux technos (React et Vue) semblées se valoir. Je ne peux donner qu’un avis empirique car je n’ai pas testé React.

Donc de ce côté-là (frontend), je n’ai rien d’autre à dire.

Côté serveur. Exrpess, c’est bien pour des petits projets. Si tu as besoin d’une base de données, tu peux toujours en ajouté. Après, si tu veux un environnement qui gère tout, tu peux utiliser Meteor, et Oh miracle, tu peux utiliser React (et même Vue) avec.

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

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).

pour mon application avec une seule page, il vaut mieux avoir une page séparée pour le login/mdp ?

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.

Édité par Heziode

+1 -0

Cette réponse a aidé l’auteur du sujet

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

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.

Kanaal

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.

Ce n’est pas parce qu’ils sont nombreux à avoir tort qu’ils ont raison - Coluche

+0 -0
Auteur du sujet

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.

+0 -0

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.

+0 -0
Auteur du sujet

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.
+0 -0

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

Ce n’est pas parce qu’ils sont nombreux à avoir tort qu’ils ont raison - Coluche

+0 -0
Auteur du sujet

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.

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

leroivi

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

+0 -0

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 ?

Ce n’est pas parce qu’ils sont nombreux à avoir tort qu’ils ont raison - Coluche

+0 -0
Auteur du sujet

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).

+0 -0

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

Édité par Heziode

+0 -0

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) ?

Édité par Heziode

+0 -0

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

Heziode

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

Édité par leroivi

Ce n’est pas parce qu’ils sont nombreux à avoir tort qu’ils ont raison - Coluche

+0 -0

Par contre je ne recommanderais pas d’utiliser MongoDB pour une application qui n’a pas besoin de stocker plusieurs To de données. Les bases MySQL classiques seront bien plus simple à mon avis.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte