03 Infrastructure de données dans un contexte Web - damiencorpataux/infradon1 GitHub Wiki

Avant de nous focaliser sur les détail du SGBD PostgreSQL et son moteur SQL, prenons un peu d'altitude pour avoir une vue d'avion, et atterrissons progressivement dans les détails du serveur PostgreSQL.

Pour élaborer un modèle de données et ensuite l'implémenter, nous avons besoin de passer par des niveaux de détail successifs - qu'il est éventuellement une bonne idée de consigner dans une documentation de projet:

• Documents conceptuels: vue d'avion (diagramme de classes)
• Documents de travail: détails importants uniquement (diagramme relationnel)
• Documents d'implémentation: tous les détails (code SQL)

Au niveau opérationnel, un SGBDR comme Postgres exécute un moteur logiciel qui gère nos modèles de données relationnels qui sont ceux qui contiennent nos structures de données et nos données (c-à-d le vrai contenu).

• Structure de données: Tout ce qui concerne la structure des tables, leurs colonnes et leur type, leur agencement et les relations entre ces tables
• Données: Tout ce qui concerne les données elles-mêmes,

On peut ici aussi parler de niveau de détail:

• Global: La Conception: Par exemple, le modèle entité-relation, Diagramme de classes
• Local: L'Implémentation: Par exemple, le SGBDR Postgres et son implémentation des standards du concept de données relationnel, le commandes SQL pour manipuler les structures et les données.

Pareil pour approcher système complet, par exemple une Application Web, Mobile ou encore un gros système d'information multi-tiers et distribué:

• Global: Nous pouvons voir son fonctionnement global, nous représenter les interactions entre les différents composants du système - vu d'avion sans nous attarder dans les détails et cas particuliers
• Local: Nous pouvons focaliser (scoper) sur un composant ou un sous-composant pour analyser le détail, les cas particuliers dans les fonctionnement de chaque élément, etc.

Nous tournons un SGBDR Postgres version 16 qui possède sa propre implémentation fonctionnelle de gestion de données relationnelles et du langage SQL permettant de les manipuler. Cette implémentation respecte les standards de modèles relationnels et de langage SQL (histoire de la norme SQL).

Ceci implique cela: nous devons donc dériver nos diagrammes relationnels vers du code SQL en respectant les spécifications d'implémentation Postgres, c-à-d la documentation technique, c-à-d la manière dont Postgres inerprète le langage SQL que nous lui donnons à exécuter.

Pour cela, nous pouvons partir sur quelques exemples de bases de données en SQL. Nous allons commencer par voir l'ensemble des composant d'un système d'information minimaliste. Il fonctionne correctement en respectant les protocoles (HTML, JS, HTTP, SQL), mais n'est pas viable en production car il n'implémente aucune sécurité, ni tenue de charge.

Monter un service de bases de données n'a de sens que si il est utilisé, c'est-à-dire qu'un client s'y connecte pour consommer ce service. Votre service SGBDR fait partie d'un tout.

A l'aide d'un exemple minimaliste, nous allons démontrer les composants d'une Webapp et les interactions qu'il existe entre eux. Cette Webapp est à l'état de POC, voire MVP:

• POC: Proof of concept
• MVP: Minimal viable product

L'implémentation de cet exemple a l'inconvénient de ne pas pouvoir être évolutive. Mais elle a l'avantage de démontrer les interactions entre les composants (Navigateur, service HTTP, service SGBDR) avec un minimum de couches - nous pouvons ainsi observer les éléments fondamentaux.

Ceci permet aussi de bien délimiter le rôle et les responsabilités d'un service SGBDR.

Votre serviteur va vous faire la démo d'une App Web: https://github.com/damiencorpataux/infradon1/tree/main/examples.

Mais d'abord, explications vue d'avion, voici un schéma de composants de l'App Web. Laissez-moi vous raconter:

Nous schématisons ici l'ensemble du système d'information composant l'Application Web. Nous sommes au niveau de détail conceptuel et implémentation mélangés pour avoir une vue globale de ce qui est important - j'ai donc fait des choix de détail pour chaque élément.

Légende:

• En bleu: Les composants client, ils consomment un service
• En rouge: Les composants serveur, ils fournissent ce service
• Flèches: Interactions réalisées et protocoles utilisés, ils permettent aux services d'être fonctionnels et consommés

Ce qui est important:

• Voir les couples client-serveur
• Voir que chaque couple utilise son propre protocole (Postgres, HTTP) et ses propres languages (SQL, HTML/CSS/JS) et ses propres clients () qui se connectent chacun au service corresponsant (SGBDR Postgres, HTTP Script bash ad-hoc) - et donc sur le port réseau correspondant (ports 5432, port 80) de la machine serveur correspondante (par exemple localhost ou pingouin.heig-vd.ch ou les deux).

Nous pouvons observer ces couples client-serveur:

• Client-serveur Postgres - pour stocker et fournir les données (psql)
• Client-serveur HTTP et REST - fournit le JS/HTML au navigateur: la logique applicative et son UI, et fournit les données au format JSON de la part de postgres jusqu'au navigateur (via netcat)
• Client-serveur DNS, DHCP, etc. - hors scope de notre architecure, ce sont des services omniprésent et fondamentaux car inhérent au fonctionnement d'internet
• Application: Eh bien c'est l'ensemble des 3 éléments ci-dessus, mis enseble...

De manière plus précise, nous pouvons voir:

• La chaine client-serveur:
  Client HTTP (naviageur) ↔ Service HTTP / psql (serveur web) ↔ Service SGBDR (base de données)
• L'existence des couples client-serveur DNS et DHCP (ceci est hors scope de l'Application: ce sont des services internet fondamentaux, utilisé partout et tout le temps)
• Le service HTTP qui est en fait le backend (Controller: ici un script bash) faisant le lien entre
  • le frontend (View, du JS/HTML chargé dans le naviageur)
  • et le service SGBDR (Model, exprimé en SQL) - c'est notre domaine pour ce cours

Donc, un client peut faire partie d'un service consommé par un autre service (chaîne de couples clients-serveur), comme dans les applications d'exemple que nous voyons ici.

Afin de comprendre ce qui se passe en termes d'interaction, rendez-vous sur le README du répertoire d'exemples, dans la partie code de notre dépot github.

Vous pouvez reproduire chez vous les manipulation, si nécessaire en utilisant le shell systàme (bash) du serveur pingouin.heig-vd.ch, afin d'avoir les outils pour effectuer les opérations (le shell bash ou zsh et les logiciels CLI: psql, ncat et curl).

Vous devez comprendre ce qui se passe, particulièrement du point de vue du service SGBDR Postgres:

• La mise en place de la database (import du SQL contenu dans le fichier .sql)

• Avoir conscience que le serveur Postgres est un logiciel qui écoute au port :5432, ce qui en fait un service

• Comprendre que n clients peuvent se connecter au service SGBDR Postgres via le réseau (ou directement via le socket unix) et exécuter des instructions SQL

• Comprendre qu'il existe plusieurs types de clients PostgreSQL:

  • Le logiciel psql, avec une interface utilisateur sous forme de ligne de commande (CLI)

  • Le logiciel PgAdmin4, avec une interface utilisateur sous forme graphique (GUI)

  • Les librairies afin de créer un client postgres au sein de code Java, PHP ou Python (utilisé pour monter un back-end)

    • ici, notre service HTTP écrit en bash, qui utilise simplement la commande CLI psql)
    • voici un exemple de librairie en Python: https://www.psycopg.org/psycopg3/docs/basic/usage.html

• Identifier les éléments clé et leur intéractions - la mécanique des choses et le respect des protocoles:

  • Le front-end, c-à-d l'interface utilisateur de l'application web µessenger, c-à-d votre nativateur (qui exécute la logique applicative écrite en Javscript) ne peut pas interagir avec les données en accédant (en discutant) directement au service SGBDR
  • Le code Javascript éxécuté passe par un intermédiaire (le back-end) qui transforme les requêtes HTTP en requêtes SQL et transforme les réponses du SGBDR en réponses HTTP contenant les données converties au format JSON à l'attention du code Javascript qui va afficher ces données à l'utilisateur en manipulant le contenu HTML de la page web

• Etre conscient que pour démontrer le fonctionnement global de cette Web App minimaliste, nous sommes passés dans différents domaines:

  • Données en SQL/Posgres/MachineLocale sons oublier notre Conceptuel en Diagramme de classe/Relationnel/SQL
  • Back-end en Bash/HTTP/SQL/psql
  • Front-end en HTML/JS/HTTP/Navigateur

• Nous avons aussi utilisé différents niveaux de détail pour nous expliquer ce que se passe (la mécanique des choses). Vous imaginez bien, il ne faut pas apprendre par coeur le dialogue HTTP pour l'examen, mais vous devez avoir une idée de quoi il est fait.
  En revanche, pour le dialogue entre psql et le service Postgres, la seule bonne préparation pour l'examen et de le pratiquer.

---

Si vous n'êtes pas présent à cette séance, il vous est fortement recommendé de la rattraper en communiquant avec vos collègues - une grande quantité de connaissance est transmise par la pratique ce jour-là.