Récap séquences précédentes

• Introduction architecture 3 couches
• Langage PHP
• Couches accès aux données avec Doctrine
• Appli Todo (et Mini-Allociné) en ligne de commande / console
• Démarrage du projet

Rappel architecture « classique »

Rôle du serveur HTTP

1. Comprendre les requêtes HTTP des clients
   • URL (http(s)://example.com/hello)
   • Verbe/méthode/action (GET, POST, …)
   • En-têtes
   • Données transmises
2. Construire la réponse
   • Servir des documents
   • Ou exécuter des programmes
3. Renvoyer une réponse au client (HTML, etc.)

Mais aussi

• Vérifier la sécurité
• Gérer les performances
• …

Exemples

• Apache
• Nginx
• PaaS (Platform as a Service) prêt à l’emploi sur un Cloud, par ex. platform.sh

Démo

Apache dans une VM

Exécution d’appli Web à la demande

Serveur Web allumé en permanence. Application lancées à la demande.

1. Serveur Web attend des requêtes
2. Quand une requête HTTP particulière survient, déclencher votre programme
3. recommencer

Si plusieurs requêtes de plusieurs clients différents au même moment, même programme exécuté plusieurs fois en parallèle

Traitement typique d’une requête

• Le serveur Web invoque un programme
  • Programme s’exécute sur « plate-forme » : langage, etc.
  • Programme fournit sortie au format HTML (en général) : transmise « telle-quelle »

Multi-tâches

Gère plusieurs clients se connectant simultanément :

• au même serveur Web
• à la même application

… des centaines par secondes, OK ?

Concurrence d’exécution sur le serveur

Concurrence d’exécution sur le serveur

Concurrence d’exécution sur le serveur

Remarque : par défaut, les applications se terminent à la fin de la réponse à une requête. La requête 3 redémarre une requête. L’exécution pour la requête 1 du même client est oubliée.

Performances ?

Gère plusieurs clients se connectant simultanément :

• au même serveur Web
• à la même application

… des centaines par secondes, OK ?

Simplifions :

• 1 seul serveur Web, il gère OK (ressources statiques)
• démarrage centaines contextes application applications en parallèle… file d’attente utile ;-)

Technologies d’invocation d’un programme

• Différentes façons d’appeler un programme

• Exécution :

  • Directe sur le système d’exploitation : CGI (Common Gateway Interface)

  ou

  • Dans le contexte d’un serveur d’applications :
    • un module au sein du serveur Web
    • ou un serveur d’application séparé (aujourd’hui)

Pour les archéologues : CGI

Common Gateway Interface

• Requête sur une URL invoque une exécution d’un processus sur l’OS : shell script, exécutable compilé, script (Perl, Python, …)
• Point d’entrée du programme unique : programmation impérative « classique »
• Problèmes :
  • lourdeur de l’invocation d’un nouveau processus système à chaque requête
  • gestion de session difficile
  • sécurité : celle de l’OS

Obsolète !

« Au sein » du serveur HTTP

• Le serveur HTTP « intègre » des fonctionnalités pour développer des applications (via des « plugins »):
  • Langage de programmation « embarqué » (PHP, Python, …)
  • Gestion « native » de HTTP
  • Génération « facile » de HTML, etc.
• Exécution dans des threads dédiées (plus efficace que des processus à invoquer)
• Transfert des données immédiat : en mémoire, sans passer par l’OS

Serveur d’applications séparé

• Le serveur Web gère la charge HTTP et fournit des documents statiques (CSS, images, etc.)
• Un (ou plusieurs) serveur(s) d’applications gère(nt) l’exécution des réponses dynamiques aux requêtes
• Le serveur HTTP et les serveurs d’application sont connectés de façon efficace (si possible)
• Le serveur d’application gère des sessions
• Rend indépendantes partie statique et partie dynamique : s’adapter à la charge plus ou moins dynamiquement.

Au final, peu importe : nos programmes sont démarrés sur la plate-forme d’exécution le temps de traiter une requête, puis s’arrêtent.

Exemple : plate-forme applications Web en PHP

Serveur d’exécution PHP dédié : PHP-FPM (FastCGI Process Manager)

• Embarque l’interpréteur du langage PHP
• Facile à tester : très populaire pour déploiement chez des hébergeurs (ex. nginx + php-fpm)
• Conserve des mécanismes très proches de la façon d’écrire les programmes en scripts CGI et de s’interfacer avec le serveur Web (FastCGI)
• Large choix de bibliothèques. Par exemple Symfony pour programmer les applications Web en objet

Démo

PHP « derrière » Apache, avec php-fpm

Serveur classique et recopie du code

Exemple: avec FTP sur serveur Apache + PHP + SGBD

Automatisation sur PaaS avec Git

Git push vers un hébergement Cloud PAAS (Platform as a Service)

Exemple: avec commande symfony deploy sur platform.sh

Concevoir les programmes

Objecif : programmation événementielle :

1. définir des chemins d’URL, et autres éléments de contexte qui déclencheront l’exécution du code
2. écrire les différents morceaux de code qui doivent s’exécuter quand les requêtes HTTP arrivent sur chacun de ces chemins

Exemple :

• GET sur /todo/list appelle
  TodoController::index()
• GET sur /todo/show/{i} appelle TodoController::show($todo)

Contexte d’invocation

• Données transmises au serveur Web dans la requête HTTP :

  URL

  Arguments (URL-encoded)

  En-têtes

  Cookies

  Données

  contenu (payload) de la requête (ex. données de formulaires pour un POST)

• Le choix du programme à invoquer est déterminé par une combinaison d’éléments (a minima via le chemin dans l’URL)
  • La configuration du serveur détermine les règles à appliquer

Invocation des programmes

• Le serveur Web extrait le contexte des données reçues dans la requête (peut les filtrer)
• Le serveur d’application lance un « processus » pour le programme demandé
• Il transmet les données de contexte au programme
  • arguments d’un processus (CGI / FastCGI)
  • variables d’environnement (CGI / FastCGI)
• La plate-forme d’appli Web du cadriciel/langage :
  • appelle une fonction/méthode d’une API interne
  • passe en paramètres les variables extraites du contexte de la requête
  • …

Propagation invocation

Résultats d’exécution

En POSIX, exécution d’un processus :

• Statut d’une exécution de processus :
  • Code de retour système
    • 0 (succès)
    • ou != 0 (erreurs)
• Résultats :
  • Sortie standard du programme (stdin)
  • Erreur standard (stderr) ?

Idem en CGI, FastCGI, etc.

Conversion pour HTTP en contexte Web

Construction de la Réponse HTTP

• Code de retour -> Code de statut

  Exemple :

  Succès	0	⇒	200
  Erreur	!= 0	⇒	5xx

• Sorties
  • Standard (stdout) telle-quelle dans réponse HTTP : attention au format
    • Headers : succès, échecs, redirections, …
      • Cookies : sessions
    • Ligne vide
    • Contenu du document :
      • HTML
      • Autres formats (APIs : JSON, …)
  • Erreur standard (stderr) : dans les logs du serveur ?

Serveur HTTP intégré à PHP

Permet de tester comportement serveur d’application PHP simplement en local

• Démarrage :

  php -S localhost:8000 -t public/  
  

• Exécution script PHP demandé dans la requête, si présent dans public/, (ou par défaut, par public/index.php)

Exemples :

API Web

Principes d’une Application Programming Interface (API) objet d’une application Web, invoquée par le serveur d’application, dans un paradigme de programmation évenementielle.

Appel de méthode

• Objets : instances de classes (encapsulent un état)
• Méthodes : récepteurs de messages

Exemple : envoi du message « execute » à une commande

  class Application {
      public run() {
          //...
          $command = new ListTodosCommand();
          $res = $command->execute();

Modèle de programmation événementielle

Identique dans beaucoup de systèmes de programmation d’interfaces (GUI, HTTP, …) :

• objets gestionnaires d’interface
• méthodes activées par des événements

Réception d’une requête HTTP => appel de méthode

Contrôleurs HTTP

Appel de méthodes dans une classe conçue pour gérer des actions (HTTP) sur des ressources (Web)

• Classe contrôleur (Controller)
• « écoute » des événements : requêtes HTTP sur des ressources particulières propres à cette classe
• gère les actions spécifiques à effectuer (et délègue au reste du code)

Patron de conception Model, Vue, Controller (MVC)

Programmer les méthodes d’un contrôleur

• Le programmeur n’écrit pas le point d’entrée index.php
• Le framework fournit un composant offrant des fonctions de routage : décodage du contexte HTTP pour invoquer la bonne méthode de la bonne classe
• Le programmeur n’a plus qu’à écrire des méthodes dans une classe PHP : programmation événementielle dans un contexte objet

URLs « lisibles »

Aiguillage des requêtes :

• URLs sans extension .php
• Tout est géré par index.php, qui passe la main au routeur

Rôle du kernel Symfony

Faire la conversion entre le mode d’invocation classique de PHP, hérité des CGI d’origine, et le mode objet moderne.

Le programmeur Symfony n’a plus qu’à s’occuper :

• déclarer le routage
• coder les classes contrôleurs

Routage

• Le programmeur associe :
  • schéma de chemin d’URL
  • méthode d’une classe PHP « Contrôleur », à invoquer au traitement d’une requête
• Le composant « Routeur » réalise les appels vers les bonnes méthodes

Exemple HomeController

• Code : src/Controller/HomeController.php
• Gère :
  http://localhost:8000/
• Classe PHP HomeController
  • Méthode indexAction()

Route :

Exemple TodoController

• Code : src/Controller/TodoController.php
• Gère :
  • http://localhost:8000/todo/
  • http://localhost:8000/todo/42
• Méthodes de la TodoController :
  • listAction()
  • showAction(id)
• Routes :

Méthodes gestionnaires de requêtes

Définition des routes avec annotations Route (attributs PHP 8)

class TodoController extends Controller {
    /**
     * Finds and displays a todo entity.
     */
    #[Route('/todo/{id}', name: 'todo_show',
            requirements: ['id' => '\d+'], methods: ['GET']) ]
    public function showAction(Todo $todo): Response {
        return ...;
    }
}

• path (arguments optionnels : {id})
• name (obligatoire)
• requirements (optionnels. Ici id est un entier)
• methods (optionnel)

Exécution éphémère

Traitement d’un événement (réception d’une requête HTTP)

Temps de vie de l’application : appel d’une méthode de contrôleur

1. Initialisation cadriciel + routage
2. Exécution méthode du contrôleur
   1. Chargement données depuis base (et/ou session)
   2. Traitements
   3. Sauvegarde en base (et/ou session)
   4. Retourne une réponse (inclut données/document …)
3. Envoi Réponse HTTP
4. Mort

Répété à chaque requête

Take away

• serveur HTTP
• serveur application
• invocation des programmes qui génèrent du HTML
• programmation événementielle
• routage + controleurs Symfony
• méthodes des contrôleurs décorées avec Route

Séance TP n°4

• Découverte Contrôleur Web Symfony, sur ToDo
• Ajout Contrôleurs Web dans projet

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.