Aller au contenu

Vue d'ensemble de l'architecture

Introduction

Cette page présente l'architecture globale de la plateforme Feelbat.

Elle donne une vue d'ensemble des applications, des services backend et des différents systèmes de stockage utilisés par la plateforme.

Objectif

À la fin de cette page, vous comprendrez :

  • Les grandes briques de la plateforme.
  • Le rôle des applications web et mobile.
  • Le rôle des principaux services backend.
  • Où sont stockées les principales données.
  • Comment les applications communiquent avec les services.

Architecture générale

Le schéma ci-dessous présente une vue simplifiée de l'architecture actuelle de la plateforme.

Il met en évidence les principales briques du système et leurs interactions. Les détails d'implémentation seront abordés dans les pages dédiées de cette section.

Vue d'ensemble de l'architecture

Vue simplifiée de l'architecture de la plateforme Feelbat.

Applications

La plateforme est utilisée à travers plusieurs applications clientes.

Dashboard web

Le dashboard web est l'application principale utilisée depuis un navigateur.

Il permet d'accéder aux fonctionnalités de supervision, de gestion et d'administration de la plateforme.

Application mobile

L'application mobile est utilisée sur le terrain.

Elle communique avec le backend via le gateway GraphQL et conserve également certaines données localement grâce à AsyncStorage.

Ce stockage local permet notamment de gérer :

  • le cache Apollo ;
  • les tokens d'authentification ;
  • certaines données nécessaires au mode hors connexion.

Services backend

Les services backend exposent les fonctionnalités métier de la plateforme.

Service Responsabilité principale
legacy-gateway Point d'entrée GraphQL utilisé par l'application mobile.
legacy-auth Gestion de l'authentification et des utilisateurs.
legacy-mailing Dispatch des emails, SMS et notifications.
legacy-rs-manager Gestion des ressources métier (projets, modules, alertes, etc.).
legacy-metrics Traitement et exposition des données provenant des capteurs.
web-connector Point d'entrée des webhooks externes (ex. Sigfox).
mqtt-connector Point d'entrée et de sortie des communications MQTT avec les capteurs.
sensors Gestion du domaine des capteurs. À terme, ce service remplacera toute la gestion des capteurs actuellement présente dans legacy-rs-manager.
remote-action Gestion des actions distantes exécutées sur les capteurs. À terme, il remplacera le système de planned-actions.
configuration Gestion des configurations complexes qui ne sont pas adaptées à une modélisation SQL classique (templates PDF, configurations de normes, etc.).

Tip

Chaque service doit rester propriétaire de son domaine métier. Un service ne doit pas modifier directement les données appartenant à un autre domaine.

Stockages

La plateforme utilise plusieurs systèmes de stockage selon le type de données manipulées.

auth-db

Base de données dédiée à l'authentification.

Elle contient notamment les données liées aux utilisateurs et à l'authentification.

resources-manager-db

Base de données principale des ressources métier.

Elle contient notamment :

  • les projets ;
  • les modules ;
  • les seuils ;
  • les alertes.

InfluxDB

InfluxDB est utilisé pour stocker les mesures provenant des capteurs.

Ce stockage est adapté aux séries temporelles et aux données de mesure.

AsyncStorage

AsyncStorage est utilisé côté mobile pour stocker localement certaines données.

Il permet à l'application mobile de conserver des informations utiles même lorsque la connectivité réseau est limitée.

Flux général

Le flux principal est le suivant :

  1. Les applications web et mobile envoient leurs requêtes au legacy-gateway.
  2. Le gateway redirige les requêtes vers les services backend concernés.
  3. Chaque service backend interagit avec son propre stockage ou avec le stockage dont il est responsable.
  4. L'application mobile peut également lire ou écrire certaines informations localement dans AsyncStorage.

Limites du schéma

Cette page représente uniquement une vue d'ensemble de l'architecture.

Elle ne détaille pas encore :

  • les communications asynchrones ;
  • Kafka ;
  • les règles de découpage des services ;
  • l'architecture interne d'un service ;
  • les conventions de mapping entre couches.

Ces sujets sont documentés dans des pages dédiées.

Pour aller plus loin

Les pages suivantes complètent cette vue d'ensemble :

À retenir

  • Les applications clientes passent principalement par le legacy-gateway.
  • Chaque service backend possède une responsabilité métier claire.
  • Les données sont séparées selon leur nature et leur domaine métier.
  • Les mesures capteurs sont stockées dans InfluxDB.
  • Le mobile utilise AsyncStorage pour certaines données locales.
  • Cette page est une introduction : les détails d'architecture sont traités dans les pages dédiées.