Quand utiliser «routage côté client» ou «routage côté serveur»?

Je suis un peu confus à ce sujet et je me sens un peu stupide de poser cette question, mais je veux comprendre.

Donc, disons que je travaille avec un framework Web côté client, comme Backbone, Angular ou Durandal. Ce cadre inclut le routage.

Mais bien sûr, j’ai toujours un serveur pour les bases de données, et ainsi de suite.

Ma question est maintenant:

Quand utiliser “routage côté client” ou “routage côté serveur”?

Comment est-il “décidé” si le routage est déjà effectué côté client ou si la demande est d’abord envoyée au serveur Web?

J’ai beaucoup de mal à l’imaginer, car le client pourrait faire le routage avant que le serveur ne soit jamais au courant de cette requête.

Je serais très reconnaissant si quelqu’un pouvait expliquer comment ces deux systèmes de routage fonctionnent ensemble.

PS: Je n’ai pas inclus les exemples de code car je ne cherche pas une réponse concernant un framework particulier, mais concernant le processus de routage en général.

tl; dr:

  • avec le routage côté serveur, vous téléchargez une nouvelle page Web complète lorsque vous cliquez sur un lien,
  • Avec le routage côté client, l’application Web télécharge, traite et affiche les nouvelles données pour vous.

Imaginez que l’utilisateur clique sur un simple lien: Hello!

Sur une application Web utilisant le routage côté serveur :

  • Le navigateur détecte que l’utilisateur a cliqué sur un élément d’ancrage.
  • Il fait une requête HTTP GET à l’URL trouvée dans la balise href
  • Le serveur traite la demande et envoie un nouveau document (généralement HTML) en réponse.
  • Le navigateur supprime l’ancienne page Web et affiche celle qui vient d’être téléchargée.

Si l’application Web utilise le routage côté client :

  • Le navigateur détecte que l’utilisateur a cliqué sur un élément d’ancrage, comme précédemment.
  • Un code côté client (généralement la bibliothèque de routage) intercepte cet événement, détecte que l’URL n’est pas un lien externe, puis empêche le navigateur d’effectuer la requête HTTP GET.
  • La bibliothèque de routage modifie ensuite manuellement l’URL affichée dans le navigateur (en utilisant l’API HTML5 History, ou peut-être des hashbangs d’URL sur les anciens navigateurs).
  • La bibliothèque de routage modifie ensuite l’état de l’application client . Par exemple, il peut modifier le composant racine React / Angular / etc en fonction des règles de routage.
  • L’application (en particulier la bibliothèque MVC, comme React) traite ensuite les changements d’état. Il rend les nouveaux composants et, si nécessaire, demande de nouvelles données au serveur. Mais cette fois, la réponse n’est pas nécessairement une page Web entière, elle peut aussi être des données «brutes», auquel cas le code côté client le transforme en éléments HTML.

Le routage côté client semble plus compliqué, car c’est le cas. Mais certaines bibliothèques facilitent vraiment la vie de nos jours.

Il existe plusieurs avantages du routage côté client: vous téléchargez moins de données pour afficher le nouveau contenu, vous pouvez réutiliser les éléments du DOM, afficher les notifications de chargement pour les utilisateurs, etc. Cependant, les applications Web générant le DOM moteurs), facilitant ainsi l’optimisation du référencement. La combinaison de ces deux approches est également possible, l’excellent Flow Router SSR en est un bon exemple.

Je pense que le routage côté client est utilisé par les applications à page unique, où le site réel n’est jamais laissé.

Le routage fonctionne en se connectant à la page en cours, sur laquelle réagissent les infrastructures de routage côté client.

index.html # / mysubpage

Le routage côté serveur est similaire à celui d’Apache par défaut lors de l’appel d’un sous-site par son URL, mais node.js le fait en utilisant des itinéraires car les fichiers html doivent d’abord être rendus.

Si vous avez un SPA avec une infrastructure de routage côté client et que vous utilisez Node.js, vous avez toujours besoin du routage côté serveur pour basculer entre les sites.

Les applications modernes utilisent souvent le routage côté client et le routage côté serveur de manière «mixte» ou «hybride», il est donc assez difficile de tracer une ligne entre ces deux techniques.

Pour mieux comprendre quand et comment utiliser le routage côté serveur et le routage côté client, vous devez probablement déterminer ce qu’il se passe lorsque vous utilisez une application volumineuse utilisée pour gérer une grande entreprise de fabrication (cela ne se produit pas souvent dans le monde réel, c’est juste un exemple utile).

Dans ces cas, vous aurez probablement des personnes différentes (avec des rôles différents) qui verront différentes parties de cet environnement complexe (différents aspects ou domaines ). Par exemple, un ingénieur verrait un serveur de fichiers avec beaucoup de documents numériques pendant que les personnes travaillant dans la cantine de l’entreprise verraient le menu à préparer, le calendrier de travail et le magasin. Ce sont des “domaines” d’application totalement différents qui nécessitent des interfaces utilisateur totalement différentes. Il est donc judicieux de servir différents SPA à chaque type d’utilisateur.

Dans ce cas, vous pouvez utiliser le routage côté serveur pour diffuser une interface utilisateur spécifique (SPA) à un utilisateur spécifique, tandis que vous pouvez utiliser le routage côté client pour naviguer dans cette interface utilisateur (et charger les données). Pensez à ces SPA comme des “tableaux de bord” ou “tableaux de bord” consacrés à des “tâches” spécifiques et utilisés par des types spécifiques de “professionnels”.

Par exemple, vous pourriez avoir un itinéraire / myapp / engineering pour vous tous, ingénieurs et / myapp / cantine pour tout le personnel de votre cantine. Chacune de ces URL représenterait un domaine spécifique et servirait un tableau de bord spécifique à un type d’ utilisateur spécifique. Ces URL seraient gérées côté serveur .

Au lieu de cela, vous utiliseriez le routage côté client pour naviguer dans chacun de ces tableaux de bord , charger les données et reconfigurer l’interface utilisateur si nécessaire.

Bien entendu, votre application aura probablement également une API RESTful utilisée par vos SPA pour récupérer les données dont ils ont besoin. Les URL appartenant à l’API REST doivent être gérées côté serveur pour effectuer leur travail (même si elles ne sont PAS associées à de véritables pages HTML) et ne sont invoquées que par vos SPA «en arrière-plan». Ils sont généralement conservés dans un “domaine” séparé tel que / myapp / api.

La même chose se produit avec la page Web statique (comme la page “contacts” et la page “à propos”) qui sont généralement conservées dans un dossier / myapp / static (ou “domain”) et côté serveur (ce dossier ou “domaine” peut être – et est souvent – hébergé sur un serveur différent).

Ainsi, vous devez probablement utiliser le routage côté serveur pour séparer les domaines d’applications les uns des autres et le routage côté client pour naviguer dans chaque domaine.