Gatbsy.js, React et GraphQL pour nos documentations

Au cours des derniers mois, j’ai consacrer un peu de temps à la ré-écritures de quelques sites Web pour nos projets Open Source. Ces sites incluent le projet CSV de Node.js, le client HBase pour Node.js et le projet Nikita, notre outil d’automatisation du déploiement de systèmes. J’ai utilisé plusieurs générateurs de sites statiques dans le passé, mais je voulais essayer quelque chose de nouveau, performant et idéalement avec React.js ou Vue.js utilisé côté serveur. Après avoir évalué différents outils, notamment Nuxt et VuePress, j’ai décidé d’utiliser Gatsby.js, avec l’avantage supplémentaire de pouvoir expérimenter GraphQL.

Les origines de Gatsby.js

Gatsby.js a été créé il y a environ 3 ans par Kyle Mathews à une époque où React.js et GraphQL rencontrait un certain succès auprès de la communauté. Il s’est étendu au fil du temps avec un service de plug-in et un large écosystème en pleine croissance. En s’appuyant sur 2 technologies au bon moment, il a attiré des premiers utilisateurs influants en faisant participer des personnes et des organisations telles que les équipes de Facebook et de GraphQL. Dans le même temps, les headless CMS et les services tels que Netlify commençaient également à gagner du terrain. À la sortie de la v1 en juillet 2017, un noyau dur composé de centaines de contributeurs avait émergé.

Gasby.js est un générateur de sites statiques et rapides, mais également une entreprise en démarrage qui a non seulement construit un produit, mais également une communauté. En mai 2018, Gatsby.js a effectué une levée de fond initiale de 3,8 millions de dollars et est maintenant une startup. Comment un projet de générateur statique, basé sur une technologie qui existe depuis plusieurs années sans beaucoup d’innovation, a-t-il collecté 3,8 millions de dollars pour devenir une entreprise ?

Dans l’approche traditionnelle, l’utilisateur demande une page au serveur et le serveur crée la page pour la renvoyer. Désormais, avec les générateurs de sites statiques, tout est précompilé à l’avance et servi à l’utilisateur final. La limite de cette approche est que le temps nécessaire à l’étape de la construction peut devenir énorme pour des grands sites Web, malgré le fait que Gatsby.js soit très rapide et s’accélère après chaque génération. Tout en prenant quelques secondes pour la majorité des sites Web, cela peut prendre de quelques minutes à quelques heures pour les plus grands. Dans ce cas, il devient impossible de publier de nouvelles versions du site Web à chaque modification. Gérer la simultanéité des mises à jour et attendre trop longtemps avant la publication n’est pas toujours acceptable. En tant que produit commercial, Gatsby.js s’attachera à fournir une infrastructure adaptée, des services de conseil ainsi que des outils personnalisés pour prendre en charge les versions incrémentielles.

Gatsby.js en tant que produit open source doit rester inchangé. Tout le monde pense que le mot statique signifie prendre un quelques données, les traiter et en extraire des pages HTML. Gatsby.js va un peu plus loin sur plusieurs fronts.

Premièrement, il est très axé sur la performance. Deuxièmement, il est capable d’agir en tant que consommateur de données universel.

Performances

Lorsqu’un site Web est créé via Gatsby.js, il gère automatiquement la division du code, la minimisation, toutes les optimisations nécessaires, comme le préchargement de la page suivante en arrière-plan, le traitement et le redimensionnement des images. Le site qui a été construit, sans aucune intervention spécifique, fonctionne déjà mieux que la moyenne dès sa première version. Cela est encore plus important de nos jours avec l’annonce de Google, il y a quelques mois, qui utilise la performance des sites sur mobile comme indicateur dans le classement des moteurs de recherche.

Lancé par Netlify, le JAMstack (JavaScript, API et balisage) est un nouveau moyen de créer des sites Web et des applications offrant de meilleures performances, une sécurité accrue, un coût de dimensionnement réduit et une meilleure expérience de développement. Il s’appuie sur JavaScript côté client, des API réutilisables et des balises prédéfinies. Il n’est plus concerné par le backend et les infrastructures spécifiques. Gatsby.js fournit la conception et les éléments de base pour mettre en œuvre les meilleures pratiques de JAMstack :

- Projet entier sur un CDN
- Tout repose dans Git
- Outils de Build Modernes
- Builds Automatisées
- Déploiements Atomiques
- Invalidation Instantanée du Cache

Dès sa première exécution, un site Gatsby.js obtient d’excellents résultats aux tests de Lighthouse et il est presque trivial de réussir tous les tests avec le score maximal. Lighthouse est un outil Open Source automatisé publié par Google pour améliorer la qualité des pages Web. Il comporte des audits de performance, d’accessibilité, d’applications Web progressives, etc. Pour vous faire une idée, voici un extrait rapide de certaines des exigences attendues par Lighthouse :

- Performances : pas de scripts bloquants, chargement d’images en différé, règles de cache, timing de rendu, utilisation du CPU, …
- Progressive Web App : utilisation des manifestes, du service worker et de l’API de cache, écran de démarrage, ..
- Accessibilité : utilisation correcte des attributs aria, méta-informations, paramètres locaux, …
- Meilleures pratiques : HTTPS, HTTP / 2, doctype, aucune sortie d’erreur, …
- SEO : convivialité mobile, structure de données, code de statut HTTP, …

Pour obtenir de tels résultats, Gatsby.js utilise Webpack et divers modules pour pré-configurer l’environnement de construction. Il regarde les itinéraires des pages individuelles. Grâce à React.js, il sait ce qui est sur la page, ce qui est visible dans l’ordre et scinde le code en conséquence. En fin de compte, l’utilisateur ne reçoit que les ensembles HTML, CSS et JavaScript minimaux permettant de charger la page initiale, même si la taille totale de la page est très grande.

Google considère que tout chargement de page de plus de 3s perd 50% de ses visiteurs. Sur la 3G, le temps de rendu dépasse souvent 12 à 15 secondes. Si vous suivez les recommandations du projet et utilisez les outils disponibles, comme pour le traitement des images, un site Gatsby.js prendra en moyenne 1 à 5 secondes sur cette même connexion 3G.

Voici les notes de performance de 3 sites Web que nous avons récemment construits :

• csv.js.org
  Première peinture au contenu : 1 410 ms
  Indice de vitesse : 1,410 ms
  Temps d’interactivité : 1 430 ms
  Première peinture significative : 1 410 ms
  Premier processeur en veille : 1 410 ms
  Latence d’entrée estimée : 13 ms
• hbase.js.org
  Première peinture au contenu : 990 ms
  Indice de vitesse : 990 ms
  Durée de l’interactivité : 2 590 ms
  Première peinture significative : 1 010 ms
  Premier processeur en veille : 2 480 ms
  Latence d’entrée estimée : 25 ms
• nikita.js.org
  Première peinture au contenu : 970 ms
  Indice de vitesse : 2880 ms
  Temps interactif : 4 810 ms **
  Première peinture significative : 970 ms
  Premier temps d’inactivité de la CPU : 3 400 ms
  Latence d’entrée estimée : 75 ms

** À noter que le temps écoulé avant l’interactivité dans Nikita est dû à l’animation de la zone de dessin présente sur la page d’accueil et s’applique uniquement à cette page.

GraphQL

Les données peuvent provenir de n’importe quel fournisseur, dans la mesure où elles peuvent être converties en objet JSON. Cela inclut une base de données, un point de terminaison REST distant ou des fichiers Markdown stockés localement. Gatsby.js peut consommer ces données en les plaçant dans un nœud final uniforme et central avec GraphQL. Le développeur qui travaille avec un site Gatsby.js a une surface uniforme sur laquelle travailler. Il écrit du code dans React.js et utilise les données de GraphQL. Pour les éditeurs de contenu, l’équipe de contenu peut travailler dans Wordpress, l’équipe de vente peut travailler dans Salesforce et le développeur peut rédiger sa documentation en Markdown. Personne ne doit modifier sa méthode de travail car Gatsby.js peut consommer toutes les sources et l’équipe frontend peut créer des sites incroyables sans se soucier d’où proviennent les données.

L’introduction d’une couche GraphQL au-dessus d’un projet volumineux a un impact sur la productivité de l’équipe qui interagit avec un service GraphQL centralisé au lieu de plusieurs points de terminaison REST. Il modifie la façon dont l’interface est construite en éliminant le besoin d’écrire plusieurs demandes asynchrones et en définissant uniquement de manière déclarative ce dont vous avez besoin, sans avoir à gérer les droits d’accès et l’authentification, la réconciliation des données, la surchauffe des performances, la planification des demandes qui interrompent le flux de travail du développeur. Gatsby.js s’intéresse à la fois à l’obtention des données et à leur affichage. Cela le rend unique par rapport aux autres solutions GraphQL et aux générateurs de sites statiques.

De nombreux développeurs, y compris John Resig, le créateur de JQuery, présentent GraphQL comme une alternative viable à REST. Avec la croissance des API publiques et privées, les éditeurs ont du mal à comprendre toutes les exigences requises pour intégrer ces données dans leur application et GraphQL peut vous aider dans cette affaire. C’est mieux que ce que REST a fourni.

L’avenir de Gatsby.js

Ces derniers mois, des efforts ont été fournis pour préparer et livrer la version 2 de Gatsby.js. Parallèlement à cette nouvelle version majeure, un nouveau site Web entièrement re-designé a été publié pour améliorer la navigation et enrichir la documentation.

Voici quelques attentes pour le futur proche :

• Temps de construction : bien que Gatsby.js se concentre sur la performance, il ne fait pas partie des moteurs les plus rapides en termes de génération de contenu. L’équipe a engagé plusieurs initiatives pour optimiser le processus de construction. Les constructions incrémentielles sont une autre fonctionnalité attendue dans le futur.
• Internationalisation : il n’y a actuellement pas de manière officielle pour faire de l’internationalisation, les utilisateurs doivent l’implémenter eux-mêmes. Des travaux sont attendus pour déterminer s’il incombe à Gatsby.js de gérer ces cas d’utilisation et quelles sont les meilleures pratiques pour le faire.
• Accessibilité : par le passé, l’objectif principal était de fournir des bases telle que l’exécution du plug-in d’accessibilité JSX dans la configuration ESLint. À l’avenir, ils espèrent accroître la prise en charge de l’accessibilité, notamment en trouvant une solution appropriée indiquant les changements de navigation pour les utilisateurs utilisant un lecteur d’écran.