Architecture(s) et
application(s) Web

CSC4101 - Conclusion

28/08/2023

Objectifs de cette séquence

Objectifs de cette séance (1h) :

  1. Architecture appli Web "classique"
  2. Architecture système
  3. Suite à TSP

Ce que nous avons vu

Paysage des technos

image/svg+xml Firefox Client ServeurWeb Scripts /Services Internet Nginx MySQL A B C D F E G H I J K L Code réponse Contrôleur Cookie Doctrine DOM HTML JS PHP Requête SQL TCP/IP Twig DOM HTML JS PHP SQL Twig Cookie Requête TCP/IP Coderéponse Contrôleur Doctrine

Multi-couches

multi-couches.png

Figure 1 : Modèle en plusieurs couches (tiers)

MVC

MVC-user.png

Figure 2 : Modèle - Vues - Contrôleur

appliqué aux interfaces sur le Web

MVC principalement sur le serveur

couches-MVC.png

Figure 3 : « MVC dans les couches Web »

MVC-sur-archi-2.png

Figure 4 : « Vue et Modèle »

Contrôleur : Codé en PHP objet avec Symfony

Avantages :

  • client (navigateur) stupide,
  • formulaires câblés avec modèle de données Doctrine
  • cohérence des interactions HATEOS gérées par le serveur

HATEOS : Hypermedia As The Engine Of application States

Client de moins en moins stupide

HTML statique

doc-statique.png

Figure 5 : « Documents statiques »

Formulaires standards

traditional-page-lifecycle.png

Figure 6 : « Comportement des formulaires standard »

HTML dynamique

dhtml.png

Figure 7 : « DHTML »

AJAX avec JQuery

ajax.png

Figure 8 : « AJAX »

Programmation côté serveur

Programmation événementielle

  • déclenchement programmes sur serveur : requêtes HTTP
    • méthodes des classes PHP des Contrôleurs Symfony, réflexes cablés sur des routes

D’ailleurs, aussi sur le client :

  • déclenchements de programmes dans le navigateur en Javascript, quand événements interface utilisateur du navigateur (+ horloge, …)
    • fonctions JS, câblés sur sélecteurs (DOM)

Concurrence d’exécution sur le serveur

parallel-apps-simple-1.png

Concurrence d’exécution sur le serveur

parallel-apps-simple-2.png

Concurrence d’exécution sur le serveur

parallel-apps-simple-3.png

Exécution de l’application

Dev vs Prod

env de tests
serveur de tests local symfony server:start
production
code déployé derrière Nginx, PHP-FPM, Cloud PaaS, etc.

Durée de vie

  • Serveur Web : tourne en permanence
  • Application :
    • redémarrée à chaque requête entrante
    • terminée après chaque réponse
    • plusieurs fils d’exécution parallèles : requêtes HTTP de différents clients HTTP

Contexte

Contexte (variables PHP) propre à chaque client HTTP

  • contexte de la requête (arguments + en-têtes + données)
  • session :
    • propre à un client / utilisateur
    • liée aux cookie …

Cohérence

  • dans le temps entre deux requêtes du même clients (HATEOS): sessions
  • entre clients : base de données partagée, dans SGBDR

Composants Symfony

  • Routeur + Contrôleur
  • Doctrine (attributs ORM, repository)
  • MapEntity (raccourci accès au chargement des objets depuis BD dans méthodes contrôleurs)
  • Gabarits Twig
  • *Type (FormBuilder + validation données)
  • Exceptions
  • Security
    • rôles RBAC, permissions
  • Session
    • Cookies

Mais aussi

  • Data fixtures
  • Générateurs de code
  • Barre d’outils de mise au point
  • …

Notions clés architecture « classiques »

  • Client s - serveur s avec HTTP
  • Multi-couches :
    • Présentation HTML + CSS,
    • Traitements : PHP objet,
    • Modèle : ORM + SGBD
  • Code essentiellement sur serveur (PHP + Symfony)
  • Programmation événementielle (MVC)
  • REST (HATEOS, …) + Sessions

Objectifs de cette séquence

Objectifs de cette séance (1h) :

  1. Architecture appli Web "classique"
  2. Architecture système
  3. Suite à TSP

Architecture Web générale

architecture.png

Figure 9 : « Composants utilisés »

Application Web + services additionnels

web-archi-101.png

Figure 10 : « Composants utilisés »

Source : Web Architecture 101 de Jonathan Fulton

infrastructure-symfony-book.png

Source : diagramme de l’infrastructure finale du livre Symfony: The Fast Track

</système>

Approfondir

Ce qu’on n’a pas vu

Autre jeu de slides : « Évolution des architectures applicatives »

Conclusion de la conclusion

Développer des applications Web

  • Web : OK
  • Reste problèmes applicatifs, conception
  • Productivité (ex. formulaires Symfony)
  • Qualité logicielle
    • Tests automatisés (une fois codés)

La « suite » en CSC4102 !

Postface

Crédits illustrations et vidéos

Copyright

  • Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
  • Réservé à l’utilisation pour la formation initiale à Télécom SudParis.