LE PAYSAGE FRONT-END : Différents types d'applications front-end.

Jan 26 2023
J'ai récemment lu le livre Building Micro-frontend et j'ai décidé de partager avec vous certains des points clés que j'ai appris du chapitre 1 : Le paysage frontal. En cela, nous couvrirons quel est le type d'application disponible dans Frontend.

J'ai récemment lu le livre Building Micro-frontend et j'ai décidé de partager avec vous certains des points clés que j'ai appris du chapitre 1 : Le paysage frontal .

En cela, nous couvrirons quel est le type d'application disponible dans Frontend.

Application micro-frontale

Il s'agit d'une architecture émergente inspirée de l'architecture des microservices.

L'idée principale est de décomposer une base de code monolithique en parties plus petites, permettant à l'organisation de répartir le travail entre les équipes.

Dans l'application micro-frontend, la logique métier et la complexité du code sont considérablement réduites, mais les frais généraux liés à l'automatisation, à la gouvernance, à l'observabilité et à la communication doivent être pris en compte.

Les équipes et les organisations sont structurées selon notre architecture souhaitée et non l'inverse.

Micro-frontend combiné avec des microservices et une forte culture d'ingénierie mais nous pouvons également le combiner avec n'importe quelle architecture Backend telle qu'un Backend monolithique ou une architecture orientée services (SOA).

Demande d'une seule page (SPA)

Il se compose d'un ou de quelques fichiers JS qui encapsulent l'ensemble de l'application FE.

Le client télécharge l'intégralité du code de l'application une seule fois, au début de son cycle de vie, et l'intégralité de la logique de l'application est alors disponible à l'avance pour toute la session de l'utilisateur. Dans SPA, lorsque nous cliquons sur un bouton, cela ne recharge pas toute la page mais la partie de la page est rendue à cause de cela, nous pouvons passer d'une partie de l'application à une autre sans attendre trop longtemps.

SPA vous permet également de décider comment nous allons diviser la logique de l'application entre le serveur et le client.

Client lourd avec serveur léger ⇒ client stocke principalement la logique.

  • Lorsque nous utilisons une application de bureau où le stockage de certaines données hors ligne était essentiel, utilisez ce type de SPA.

Pour le référencement, il est difficile de comprendre comment naviguer sur un site Web ou une application à page unique, il ne sera pas facile d'indexer tous les contenus servis par un SPA à moins que nous ne préparions un autre moyen de le récupérer.

Le téléchargement de toutes les applications en une seule fois peut avoir un inconvénient car cela entraîne une fuite de mémoire lorsqu'un utilisateur saute d'une vue à une autre et lorsque nous essayons de télécharger avec une connexion instable ou peu fiable, cela rend l'expérience utilisateur très mauvaise.

L'application ne fonctionnera pas correctement lorsque l'appareil qui charge le SPA ne dispose pas d'un matériel performant.

Il est très difficile pour une organisation avec une grande équipe de travailler sur la même base de code car cela conduira à un mélange d'approches et de décisions qui pourraient dérouter de nombreux membres de l'équipe.

Applications isomorphes

Les applications isomorphes ou universelles sont des applications Web où le code entre le serveur et le client est partagé et peut s'exécuter dans les deux contextes.

C'est bénéfique pour le temps d'interaction, les tests A/B et le référencement.

  • SEO ⇒ Dans une application isomorphe, la page est rendue du côté serveur sans avoir besoin de requêtes serveur supplémentaires. Lorsqu'il est servi, il fournit au robot d'exploration une page HTML contenant toutes les informations prêtes à être indexées immédiatement sans aller-retour supplémentaire vers le serveur.
  • A/B testing ⇒ nous pouvons bien intégrer les plateformes de test A/B sans trop d'efforts. Le test A/B consiste à exécuter une expérience simultanée entre deux ou plusieurs variantes d'une page pour voir laquelle est la plus performante.

Dans les applications isomorphes, nous utilisons également une approche hybride. Nous rendons une partie de la page côté serveur pour améliorer le temps d'interaction, puis chargeons paresseusement des fichiers javascript supplémentaires au profit à la fois de l'application isomorphe et du SPA. Nous décidons de la quantité de code partagée dans Backend en fonction des exigences du projet.

Le routage est également une partie intéressante d'une application isomorphe car nous pouvons décider de le gérer côté serveur, en ne servant qu'une page de statut chaque fois que l'utilisateur interagit avec un lien sur le client.

Une application isomorphe pourrait souffrir d'un problème d'évolutivité si un projet est vraiment réussi et visité par des millions d'utilisateurs. Étant donné que nous créons une page HTML pré-rendue sur le serveur, nous devrons créer la bonne stratégie de mise en cache pour minimiser l'impact sur le serveur.

Les applications isomorphes au niveau de l'organisation souffrent des mêmes problèmes qu'un SPA.

Page statique Site Web

  • En cela, chaque fois que les utilisateurs cliquent sur un lien, ils chargent une nouvelle page statique. C'est une méthode à l'ancienne.
  • Il est toujours utilisé pour un site Web rapide destiné à être en ligne pendant une courte période.
  • Au cours des dernières années, ce type de site Web a muté en une seule page qui se développe verticalement au lieu de charger différentes pages.
  • Certains de ces sites Web chargent également le contenu paresseux, attendant que l'utilisateur fasse défiler jusqu'à une position spécifique pour charger le contenu.
  • L'investissement sur le plan technique est assez faible.
  • Nouvelle architecture frontale (Javascript, API et balisage).
  • Il s'agit d'une architecture moderne pour aider à créer des sites rapides et sécurisés et des applications dynamiques avec Javascript/API et un balisage pré-rendu servi sans serveur Web.
  • Sa sortie est un artefact d'état composé de HTML, CSS et Javascript. Et ceci est directement servi par CDN puisque l'application ne nécessite aucune technologie côté serveur pour fonctionner.
  • L'avantage de cette architecture est de meilleures performances, une infrastructure et une maintenance moins chères, une sécurité accrue en raison de la diminution de la surface d'attaque et une intégration facile avec un CMS sans tête.