Routage côté serveur et routage côté client

La façon dont nous gérons la navigation et les modifications d’URL dans les applications Web joue un rôle central dans l’UX, les performances et le référencement. Comparons le routage côté serveur et le routage côté client.

Dans le domaine du développement Web, la façon dont nous gérons la navigation et les modifications d’URL joue un rôle central dans l’expérience utilisateur, les performances et l’optimisation des moteurs de recherche. Comprendre la différence entre le routage côté serveur et côté client est fondamental pour les développeurs. Dans cet article, nous approfondirons les spécificités de ces deux techniques de routage populaires et comparerons leurs avantages et leurs inconvénients.

Routage

Avant tout : définissons routage pour ceux qui sont peut-être nouveaux dans le concept.

Dans le développement Web, le routage fait souvent référence au fractionnement de l’interface utilisateur d’une application en fonction de règles dérivées de l’URL du navigateur. Imaginez cliquer sur un lien et voir l’URL passer de https://website.com à https://website.com/about/. C’est le routage.

Quand nous visitons le / chemin d’un site Web, nous avons l’intention de visiter le parcours d’accueil de ce site Web. Si nous visitons /aboutnous voulons afficher la page À propos, et ainsi de suite.

De nombreuses applications peuvent techniquement être écrites sans le routage, mais cela peut devenir compliqué à mesure qu’une application se développe. Définir des itinéraires dans une application est utile car on peut séparer différentes zones d’une application et protéger les zones de l’application en fonction de certaines règles.

Le routage est souvent classé en deux catégories principales :

• Routage côté serveur
• Routage côté client

Routage côté serveur

Dans une application pilotée par serveur, les requêtes vers une URL suivent souvent un modèle :

1. Le client (c’est-à-dire le navigateur) fait une demande au serveur pour une page particulière.
2. Le serveur utilise les identifiants du chemin d’accès de l’URL pour récupérer les données pertinentes de sa base de données.
3. Le serveur remplit un modèle (document HTML) avec ces données.
4. Le serveur renvoie le modèle ainsi que d’autres actifs tels que CSS/images au client.
5. Le client restitue ces actifs.
6. Pour les changements d’itinéraire ultérieurs, le client envoie à nouveau une nouvelle requête au serveuret ce qui précède est répété.

Le routage côté serveur est souvent configuré pour récupérer et renvoyer différentes informations en fonction de l’URL entrante. Écrire des routes côté serveur avec Express.js ressemble généralement à ce qui suit :

const express = require("express");
const router = express.Router();


router.get("/about", function (req, res) {
  res.send("About us");
});

Ou en utilisant Rubis sur Railsune définition d’itinéraire similaire pourrait ressembler à ceci :

get '/about', to: 'pages#about'


class PagesController < ActionController::Base
  def about
    render
  end
end

Qu’il s’agisse d’Express.js, de Ruby on Rails ou de tout autre framework côté serveur, le modèle reste souvent le même. Le serveur accepte une demande et itinéraires à un manetteet le contrôleur exécute un
action (par exemple, renvoie des informations spécifiques), en fonction du chemin et des paramètres.

Routage côté client

Dans les applications utilisant le routage côté client, le serveur fournit initialement un seul fichier HTML, quel que soit le chemin de l’URL. Ce « shell » est ensuite enrichi et manipulé par JavaScript exécuté dans le navigateur. Navigation ultérieure entre les différentes parties de l’application n’envoie pas de nouvelles demandes au serveur mais modifie plutôt le contenu affiché en fonction du JavaScript et des données chargés.

Celles-ci sont caractéristiques des applications à page unique (SPA) : des applications Web qui ne se chargent qu’une seule fois (c’est-à-dire que le serveur fournit un modèle unique) et que JavaScript est utilisé pour afficher dynamiquement différentes pages.

Le flux du routage côté client ressemble généralement au suivant :

1. Le client fait une première requête au serveur.
2. Le serveur répond avec un document HTML principal (la page unique du SPA) et les ressources associées (par exemple, JavaScript, CSS).
3. Le client interprète le JavaScript et la logique de l’application détermine le contenu à afficher en fonction du chemin de l’URL.
4. Pour les changements d’itinéraire ultérieurs, le JavaScript met à jour l’historique du navigateur et le contenu affiché sans rechargement complet de la page.

Avec le routage côté client, même si le chargement initial peut sembler plus lent parce que l’application entière (ou de grandes parties de celle-ci) est chargée, les navigations ultérieures sont rapides et transparentes, car elles ne nécessitent pas d’aller-retour vers le serveur.

Le routage côté client peut être implémenté à l’aide de diverses bibliothèques et frameworks. Par exemple, Réagir au routeur est une bibliothèque de routage côté client populaire pour les applications React :

import * as React from "react";
import { createRoot } from "react-dom/client";
import {
  createBrowserRouter,
  RouterProvider,
  Route,
  Link,
} from "react-router-dom";

const router = createBrowserRouter([
  {
    path: "https://www.telerik.com/",
    element: (
      <div>
        <h1>Hello World</h1>
        <Link to="about">About Us</Link>
      </div>
    ),
  },
  {
    path: "about",
    element: <div>About</div>,
  },
]);

createRoot(document.getElementById("root")).render(
  <RouterProvider router={router} />
);

Alors que pour les applications Vue, Vue Router est la bibliothèque de routage recommandée côté client.

const Home = { template: "<div>Home</div>" };
const About = { template: "<div>About</div>" };

const routes = [
  { path: "https://www.telerik.com/", component: Home },
  { path: "/about", component: About },
];

const router = VueRouter.createRouter({
  history: VueRouter.createWebHashHistory(),
  routes,
});

Routage côté serveur et routage côté client

Le routage côté serveur et côté client ont leur place dans le développement Web moderne. Le choix entre eux dépend souvent des besoins spécifiques du projet.

Dans routage côté serveur:

• Le serveur demande uniquement la page Web que l’utilisateur consulte, et non l’intégralité de l’application Web. En conséquence, le chargement initial de la page est souvent plus rapide puisque nous téléchargeons uniquement le contenu d’une seule page Web (pro).
• Les moteurs de recherche trouvent plus facile d’indexer les applications rendues par le serveur. Cela peut être un facteur clé pour les sites où le classement dans les moteurs de recherche est primordial (pro).
• Chaque modification d’URL entraîne une actualisation complète de la page lorsque le serveur renvoie le contenu au client. C’est le désagréable clignotant état qui est affiché à un utilisateur lorsqu’il navigue d’un itinéraire à l’autre (escroquer).
• Les modèles qui doivent rester les mêmes peuvent devoir être demandés au serveur encore et encore (par exemple, un en-tête et un pied de page qui restent les mêmes sur toutes les pages Web) (escroquer).

Tandis que dans routage côté client:

• Puisqu’il n’est pas nécessaire d’attendre une réponse du serveur après le chargement initial de la page, la navigation entre les pages Web est souvent plus rapide que les applications rendues par le serveur. De plus, l’état blanc « clignotant » n’existe plus lors de la navigation d’un itinéraire à l’autre (pro).
• Étant donné que le modèle de l’application Web entière doit être chargé à la première requête, le temps de chargement initial de la page est souvent plus long que celui des applications rendues par le serveur (escroquer).
• L’exploration des moteurs de recherche est moins optimisée. Avec les navigateurs modernes, des progrès notables ont été réalisés dans l’exploration des SPA pour les moteurs de recherche, mais cela est loin d’être aussi efficace que les sites Web routés côté serveur (escroquer).

Si l’optimisation des moteurs de recherche et la vitesse de chargement initiale des pages sont essentielles, le routage côté serveur peut être la solution. D’un autre côté, si la priorité est de fournir une expérience utilisateur dynamique, semblable à celle d’une application, le routage côté client dans un SPA pourrait être le choix idéal.

Dans le paysage technologique polyvalent d’aujourd’hui, des solutions hybrides émergent également, combinant le meilleur des deux mondes, telles que Suivant.js pour React ou Nuxt.js pour Vue, qui offre un rendu côté serveur pour les SPA, résolvant ainsi de nombreux inconvénients traditionnels du routage côté client. Nous parlerons de ces frameworks plus en détail dans les prochains articles !

En fin de compte, comprendre les nuances, les forces et les faiblesses des méthodes de routage côté serveur et côté client vous permettra de prendre des décisions éclairées qui répondent le mieux aux besoins de votre application.