Comment utiliser Gatsby.js pour créer un site e-commerce ultra-rapide

Le premier Internet était constitué de sites statiques. Chaque page consultée par un visiteur était représentée par une page HTML différente. Chaque utilisateur qui a visité un site a vu le même contenu que tout le monde.

Un peu plus tard, des serveurs Web qui pouvaient produire du HTML de manière dynamique sont arrivés. Le flux typique ressemblait à ceci : un utilisateur fait une demande qui peut ou non être protégée par un CDN. Cette demande atteint le serveur Web qui interagit avec une base de données ou des API. Sur la base des données renvoyées par la base de données ou l’API, le serveur Web crée des pages HTML et les sert au navigateur.

Historiquement, les sites statiques présentaient moins de risques de sécurité et empêchaient l’application de passer du temps par requête à générer chaque page, ce qui les rendait plus performantes.

D’un autre côté, les sites statiques rendaient difficile le partage de code entre les fichiers. De plus, un développeur avait généralement besoin de mettre à jour le contenu d’un site statique car il était écrit dans le HTML. Pour ces deux raisons, les grands sites statiques peuvent devenir difficiles et chronophages à maintenir par rapport à un serveur Web.

Contrairement aux sites statiques, les serveurs Web peuvent prendre des décisions en temps réel sur le contenu à afficher ou masquer à un utilisateur, offrant une personnalisation plus sophistiquée avec moins d’effort. Mais, générer une page Web dynamique à chaque fois qu’un utilisateur visite une page prend beaucoup de temps.

Ces dernières années, les générateurs de sites statiques tels que Gatsby.js , Next.js et Nuxt.js ont permis de trouver un juste milieu. Il est désormais possible de profiter des avantages d’un site statique en termes de performances et de sécurité, tout en ayant la possibilité de partager facilement du code et d’extraire du contenu à partir d’un CMS.

Gatsby.js permet d’externaliser une grande partie de la configuration qui accompagne la création d’un front-end en JavaScript en 2018. Il gère la configuration de Webpack, React.js, HTML et CSS pour nous afin que nous puissions simplement nous concentrer sur la construction de nouvelles fonctionnalités, tout en offrant la possibilité de les personnaliser.

Étant donné que Gatsby est un générateur de sites statiques, nous arrivons à écrire du code dans React.js au lieu d’écrire du HTML, du CSS et du JS. Les documents de Gatsby décrivent bien ce processus : pendant la création, Gatsby effectue une « version de production optimisée » qui génère des « ensembles de code HTML statique et JavaScript par route ».

Un plugin Gatsby appelé gatsby-source-contentful permet d’extraire facilement du contenu et des actifs de Contentful vers Gatsby. Nous recherchons ce contenu en utilisant GraphQL .

Il faut déployer et héberger nos fichiers statiques dans S3, et servir une version mise en cache de ces fichiers à partir de Fastly, réduisant ainsi la latence et améliorant ainsi l’expérience utilisateur.

Le mieux est de stocker tout le contenu dans Contentful afin de ne pas avoir besoin de gérer une base de données, un serveur ou un CMS personnalisé. Il est bon d’avoir également un webhook qui déclenche une compilation à partir du CMS pour démarrer un déploiement.

Circle CI est utilisé pour une intégration continue et pour lancer le flux de déploiement. Circle CI exécute Jest et Flow, exécute la compilation et vérifie qu’elle est réussie, déploie le code dans une branche de préparation et exécute les tests Cypress . Si nous sommes sur la branche principale, il reconstruit le site avec nos variables d’environnement de production et se déploie sur Amazon S3.

Nous hébergeons les fichiers statiques créés par Gatsby dans Amazon S3.

Fastly est un réseau de diffusion de contenu (CDN) à utiliser pour mettre en cache le contenu qui se trouve dans le compartiment S3 afin que nous puissions le servir encore plus rapidement à nos utilisateurs. Nous configurons Fastly pour décider du contenu que nous voulons mettre en cache et pour combien de temps, et utilisons à la fois gzip et Brotli pour servir les fichiers précompressés.

Explorons un peu plus en détail comment nous avons configuré Fastly et S3 pour fournir notre contenu le plus rapidement possible à nos utilisateurs.

Imaginez que nous ayons un utilisateur à New York. Cet utilisateur fait une demande à shopflamingo.com . Une fois l’enregistrement DNS renvoyé, nous adressons une demande à Fastly. Comme il y a un nœud Fastly à New York, la requête y sera (dans la plupart des cas).

Nous demandons au nœud Fastly s’il a mis en cache la version la plus récente du site. Si le nœud Fastly a la version actuelle en cache, il la renverra à l’utilisateur. Ce processus élimine la nécessité de poursuivre la chaîne de demandes et réduit la latence. Si le nœud Fastly n’a pas de version actuelle du site en cache, il effectuera une demande au nœud Fastly Shield pour l’obtenir.

Si le nœud Fastly Shield a la version actuelle en cache, il la retournera à l’utilisateur, en mettant à jour le nœud dans la région de l’utilisateur en cours de route. S’il n’a pas de version mise en cache, il doit demander au compartiment S3.

Après un nouveau déploiement, le premier utilisateur d’une région connaît le plus de latence. Leur demande ira jusqu’au compartiment S3, car aucun des nœuds Fastly n’a de version actuelle du site en cache. Une fois cette demande initiale effectuée, tous les autres utilisateurs de cette zone peuvent accéder au site à partir du nœud Fastly le plus proche, ce qui réduit la durée pour eux. De plus, le premier utilisateur accédera à une version mise en cache du site à partir de là, jusqu’à ce qu’une nouvelle version du site soit déployer.

Nous travaillons dur pour fournir le contenu existant à nos utilisateurs le plus rapidement possible, mais qu’en est-il du nouveau contenu? Le deuxième composant majeur de notre architecture nous permet de déployer rapidement et facilement plusieurs fois par jour.

Nous allons automatisé chaque partie de notre flux de déploiement pour éviter les étapes manuelles chronophage et pour fournir des étapes qui nous garantissent que nous ne déployons pas de code cassé pour nos utilisateurs.

Le processus démarre lorsque quelqu’un déclenche une compilation. Pour déclencher une compilation, quelqu’un envoie son code sur Github ou publie une modification dans notre CMS.

Une fois que nous déclenchons une compilation, Circle CI passe par un certain nombre d’étapes :

Si l’une de ces étapes échoue, Circle CI échouera la génération et le processus s’arrêtera.

Une fois que la construction est verte (sur la staging ou master), Circle CI pousse les fichiers statiques générés par Gatsby vers S3, et le processus décrit dans la section Architecture d’hébergement commence.

Maintenant que nous avons parlé des deux principaux composants du système, voici un diagramme de tout ce qui fonctionne ensemble.

En suivant ces étapes, nous cherchons à créer un site de commerce électronique hautement performant et c’est certainement le cas.

Librement traduit de l’anglais : article Medium
Crédit photo : https://pixabay.com/en/space-rocket-travel-science-sky-1951858/