L’acronyme SPA signifie Single Page Applications. Bien que le nom permette la déduction, cela ne signifie pas que l’application n’aura qu’une seule page. Dans cet article, nous allons voir ce que sont les applications basées sur la technologie SPA et pourquoi elles connaissent un tel succès de nos jours.
Ce qui change en fait, c’est la façon dont la page se charge. Nous sommes habitués aux applications où les pages sont rendues côté serveur, quelle que soit la technologie utilisée. Cela a un effet : chaque nouvelle page qui doit être chargée se traduit par une nouvelle demande au serveur, une demande au navigateur de charger le HTML, le CSS et le JavaScript de la nouvelle page demandée. C’est pourquoi, dans plusieurs applications web, nous voyons le navigateur prendre un « petit temps » pour charger la nouvelle page, ou nous voyons la nouvelle page être vide au départ pour être chargée ensuite. Ces comportements se produisent en raison du temps qui s’écoule entre la demande de chargement de la nouvelle page par le navigateur et la réponse du serveur avec les nouvelles structures à rendre.
Comment fonctionnent les applications SPA ?
Les applications basées sur les frameworks SPA fonctionnent différemment car il n’est pas nécessaire d’effectuer des requêtes pour charger de nouvelles pages. L’application serait « chargée » entièrement lors de la première demande, où tous les éléments HTML, CSS et JavaScript nécessaires seraient chargés en une seule fois. À partir de ce moment, lorsque de nouvelles pages devaient être chargées, elles l’étaient par le biais de routines JavaScript, ce qui éliminait la nécessité d’envoyer des requêtes au serveur pour que le nouveau contenu soit rendu.
Les applications SPA en général nous permettent d’obtenir certains avantages. L’une d’entre elles est la possibilité d’optimiser les performances de l’application en transférant tous les efforts de rendu vers le client et en permettant un trafic de données plus léger entre le client et le serveur. Une autre est la réutilisation du code grâce à des technologies comme React/React Native et Angular/Ionic, qui permet de développer avec moins d’efforts et de manière plus standardisée même les applications mobiles. Cependant, les applications SPA ont tendance à présenter certaines faiblesses, comme le fait de transférer précisément l’effort de rendu au client et, dans certains cas, des problèmes de référencement.
D’une manière générale, dans une application SPA, le chargement des ressources (telles que les CSS, JavaScript et HTML des pages) ne se produit qu’une seule fois : la première fois que l’utilisateur accède à l’application. Dans ce premier accès, tout le contenu HTML, CSS et JavaScript est déjà transféré au client. Dès lors, lorsque l’utilisateur transitera par les pages de l’application, il ne sera plus nécessaire d’adresser des requêtes au serveur pour charger ces nouvelles pages : le contenu qui leur est lié a déjà été téléchargé lors du premier accès. Ce qui se passe à ce moment-là, c’est que le contenu de la page est chargé via JavaScript, un code qui est précisément généré sur la base de frameworks SPA tels que Angular, React et Vue.js. Par conséquent, nous disons que le traitement du chargement des pages et de leurs ressources respectives passe au client, puisque JavaScript est un langage principalement côté client (il y a quelques exceptions, comme lorsque nous travaillons avec Node.js).
À ce stade, le serveur n’est plus responsable du rendu et du traitement du contenu, mais plutôt du traitement des données qui seront manipulées par l’application. Les opérations de persistance dans les bases de données ou la restitution du contenu à rendre (comme une liste de clients, par exemple) relèvent exclusivement de l’application hébergée côté serveur. Actuellement, il est courant que le serveur expose une API RESTful destinée à être consommée par une application SPA. L’application SPA communique avec cette API RESTful par le biais d’appels HTTP, transmettant des données aux formats XML et JSON. L’application côté serveur est chargée de répondre à ces appels HTTP et d’exécuter les processus de gestion et de persistance pertinents. Cette architecture présente un avantage très clair : la séparation et l’isolation complètes du back-end et du front-end. Cela permet à deux équipes de travailler sur les deux fronts en parallèle, par exemple, et permet également de mieux cibler les efforts : une personne qui est meilleure pour traiter les aspects frontaux peut diriger tous ses efforts vers les tâches liées au front-end. Il en va de même pour ceux qui ont plus d’aptitude pour le back-end.