Architecture

Une application web peut être développé en utilisant plusieurs architectures :

  • rendu côté serveur (Server-Side Rendering - SSR)
  • rendu côté client (Client-Side Rendering - CSR) - application à page unique (Single Page Application - SPA)
  • application hybride : hydratation (SSR + CSR)

Le choix de l'architecture dépend de plusieurs facteurs.

Rendu côté serveur (SSR)

Modèle "traditionnel" : le serveur génère l'intégralité du HTML pour chaque requête utilisateur. Le navigateur reçoit une page HTML complète et l'affiche directement. Chaque intéraction avec le serveur renvoie une nouvelle page HTML.

Avantages :

  • SEO Amélioré : Les moteurs de recherche peuvent facilement indexer le contenu HTML.
  • Temps d'affichage initial rapide (First Contentful Paint) : Le navigateur reçoit directement du contenu affichable.
  • Compatibilité : Fonctionne sur tous les navigateurs, même anciens, sans nécessiter JavaScript.

Inconvénients :

  • Charge serveur plus élevée : Le serveur doit générer le HTML pour chaque requête, ce qui peut être coûteux en ressources.
  • Moins interactif : Chaque interaction nécessite une nouvelle requête au serveur, ce qui peut entraîner des rechargements de page.
  • Moins flexible : La logique de présentation est étroitement liée au serveur, données et présentation sont mélangées.

Technologies courantes :

  • PHP (Laravel, Symfony)
  • Python (Django, Flask, Bottle)
  • Ruby (Ruby on Rails)
  • Java (Spring)

Rendu côté client (CSR) - Single Page Application (SPA) + API

Modèle plus "moderne" : le navigateur fait le travail de génération de la page, en fonction des données récupérées sur le serveur via une API (application programming interface). Présentation et données sont séparées.

Fonctionnement : le navigateur télécharge une page HTML unique qui contient le squelette de l'application et le code JavaScript nécessaire. Les interactions de l'utilisateur sont gérées par JavaScript, qui met à jour dynamiquement le contenu de la page en utilisant des appels API au serveur pour récupérer ou enregistrer des données. Avantages :

  • expérience utilisateur fluide : pas de rechargement de page pour les interactions, ce qui offre une expérience plus réactive et agréable, et la création d'interfaces plus dynamiques.
  • rapidité : une fois la page initiale chargée, les requêtes API sont généralement plus rapides que les rechargements de page complets.
  • séparation des logiques : la logique de présentation (JavaScript) est séparée de la logique métier (API), ce qui facilite le développement et la maintenance.
  • facilité de maintenance : l'API et l'interface utilisateur peuvent être développées et maintenues indépendamment.

Inconvénients :

  • SEO (Search Engine Optimization) potentiellement plus difficile : les moteurs de recherche peuvent avoir du mal à indexer le contenu généré dynamiquement par JavaScript (bien que certains moteurs de recherche puisse indexer les pages dynamiques).
  • temps d'affichage initial plus long : le téléchargement initial de la page unique et de tout le code JavaScript peut prendre du temps, impactant le temps d'affichage initial, l'expérience utilisateur et le SEO.
  • dépendance JavaScript : nécessite JavaScript activé dans le navigateur.

Technologies Courantes :

  • Frameworks JavaScript/Typescript (React, Angular, Vue.js) pour le frontend
  • Tout langage serveur pour l'API (Python, Node.js, Java, PHP, etc.)

Hydratation (SSR + Client-Side Rendering)

Fonctionnement : combine les avantages du rendu côté serveur (SSR) et du rendu côté client (SPA). Le serveur génère initialement le HTML de la page, comme dans le SSR. Ensuite, le code JavaScript est téléchargé et "hydrate" le HTML, prenant le contrôle de l'interaction avec l'utilisateur et gérant les mises à jour dynamiques comme dans une SPA.

Avantages :

  • meilleur SEO (Search Engine Optimization) : le contenu est initialement indexable par les moteurs de recherche.
  • temps d'affichage initial rapide : le navigateur reçoit du contenu affichable rapidement grâce au SSR.
  • expérience utilisateur fluide : les interactions sont gérées de manière réactive par le JavaScript côté client.

Inconvénients :

  • complexité : plus complexe à mettre en œuvre que le SSR ou la SPA.
  • charge serveur : nécessite une capacité serveur pour le rendu initial.
  • temps d'hydratation : un certain temps est nécessaire pour que JavaScript prenne le contrôle de l'application, ce qui peut être perceptible pour l'utilisateur.

Technologies Courantes :

  • La plupart des frameworks JavaScript modernes prennent en charge l'hydratation, y compris React, Vue.js et Angular.

Choix

Il n'y a pas de "meilleure" approche universelle. Le choix dépend du contexte. Pour les applications axées sur le contenu et nécessitant un bon référencement, le SSR ou l'hydratation sont de bons choix. Pour les applications très interactives où l'expérience utilisateur est primordiale, une SPA + API peut être plus appropriée. L'hydratation offre un bon compromis entre les deux, mais au prix d'une complexité accrue.

Programme

  • NSI 1ère : modalités d'intéraction entre l'homme et la machine
  • NSI 1ère : intéraction client/serveur, requêtes HTTP, réponses du serveur