Refonte de Scaleway.com : Next.js, TypeScript, (S)CSS Modules

Aujourd’hui, nous refondons scaleway.com (Gatsby + xstyled) pour surmonter plusieurs limites :

• temps de compilation extrêmement long : la génération complète du site dépasse les 40 minutes ;
• documentation obsolète : difficile de trouver des ressources à jour ;
• plugins non maintenus : nombreux plugins dépréciés ou incompatibles ;
• compatibilité : obstacles fréquents dans l'intégration de nouvelles librairies ;
• flexibilité : la couche GraphQL de Gatsby impose de récupérer nos données d'une certaine manière ;
• régressions : l'absence de typage des données entraîne des régressions fréquentes ;
• DX : l'expérience de développement est pénible (classes cryptiques, pas de suggestions, erreurs dans l’éditeur de code).

Le nettoyage de la base de code

Des plugins vers les librairies

En passant sur Next.js, nous pouvons désormais installer directement des librairies (MDX, Algolia, Segment…) pour lesquelles nous utilisions des plugins Gatsby, qui étaient souvent moins bien maintenus, voire obsolètes.

Un code plus clair et plus lisible

Notre logique métier était très fortement couplée aux API Gatsby.

Par exemple : un composant qui affiche une liste embarquait son propre fragment GraphQL.

Nous avons refondu nos composants pour qu’ils soient génériques et ne gèrent que l’UI. Ils sont ainsi devenus beaucoup plus facilement réutilisables et faciles à tester, ce qui a contribué à réduire la duplication de notre code.

Nous avons également adopté une nouvelle organisation par domaine (DDD, Domain Driven Design) qui a aussi accentué cette séparation entre la logique métier et les composants UI “communs”.

Cette séparation des responsabilités a accéléré la prise en main du projet par les nouveaux membres de l’équipe.

Les bénéfices de contribution Strapi

Nous avons fait le choix d’utiliser Strapi parce qu’il offre :

• une interface de contribution no-code : nécessaire pour que les personnes non-techniques puissent ajouter, modifier ou supprimer de nouvelles pages et contenus ;
• des API auxquelles nous pouvons connecter notre front-end pour récupérer ces contenus.

Grâce aux dynamic zones dans Strapi, nous mettons à disposition tout un panel de composants Strapi que les équipes de contribution utilisent pour construire des pages comme elles l’entendent.

Un nouveau Storybook pour les blocs Strapi

Nous utilisons maintenant Storybook pour documenter nos composants de manière isolée. Sur chacune de nos branches de développement un Storybook est automatiquement généré et déployé sur un bucket, ce qui facilite le processus de revue de code pour toute l’équipe.
Il peut être utilisé par les équipes de contribution pour prévisualiser les composants qu’elles veulent ajouter dans une page.
C’est aussi un outil très pratique pour l’équipe Visual Design qui peut consulter et manipuler les nouveaux composants que nous développons.

Chaque fichier Storybook vit à côté de son composant :

• Button.tsx
• Button.stories.tsx

Un code plus robuste grâce à TypeScript

L'adoption de TypeScript dans notre base de code a été une véritable révolution pour notre équipe de développement et d'intégration.

Strapi a la particularité de générer des schémas et des types pour les entités qui y sont créées. Nous utilisons ces types pour qu’il y ait une cohérence totale entre les composants Strapi et leurs composants React correspondants.

Cette stricte vérification des types nous a permis de réduire les bugs en production.

Résultat : un gain de sérénité pour l’équipe de développement et une meilleure stabilité pour les personnes qui utilisent ce que nous délivrons.

CSS Modules : simplicité et efficacité

Nous avons fait le choix de migrer du paradigme Styled Components — avec xstyled — à une approche plus native en CSS avec SCSS.

Il n’était pas rare de voir des composants de l’ancienne codebase dépasser les 300 lignes. Cela rendait l’expérience de développement assez pénible, sans parler de la syntaxe non reconnue par l’IDE et de l’absence d’aides intégrées adéquates (pas d’auto-suggestion, noms de classes obfusqués…).

Les CSS Modules sont supportés nativement par Next.js, ils nous permettent de bien séparer les principes de nos composants UI.

Exemple du contenu d’un composant :

• Button.tsx pour le code fonctionnel ;
• Button.module.scss pour le style du composant.

Avec SCSS nous bénéficions aussi de fonctionnalités avancées réutilisables, comme des mixins, rendant l'écriture des styles plus efficace.

Nous avons également utilisé les variables CSS (Custom properties) pour récupérer les valeurs d’Ultraviolet, le Design System de Scaleway.

Utilisation des Serverless Containers

L’équipe a saisi cette opportunité pour optimiser l'automatisation des différentes étapes du développement et de la gestion du code en passant par le déploiement et la livraison continue des fonctionnalités ou des correctifs.

Nous utilisons maintenant des Serverless Containers pour la plupart de nos applications, notamment pour nos environnements de développement.

Chaque demande de fusion de branche de code (pull/merge requests) dispose maintenant d’un conteneur serverless automatiquement créé par notre CI (pipeline d’intégration continue) sur lequel notre application Next.js est déployée.

Ces environnements de preview facilitent grandement le travail de revue de code car ils permettent à chaque membre de l’équipe de développement de visualiser le résultat du code modifié sans avoir à le re-générer sur sa propre machine.

C’est aussi un moyen pour les parties prenantes — stakeholders — de consulter facilement et valider les nouvelles fonctionnalités avant qu’elles ne soient fusionnées sur la dernière version de la branche de code destinée à la mise en production.

Cela nous permet également de maîtriser les coûts : ces conteneurs serverless sont automatiquement supprimés une fois les branches de code fusionnées.

Quelques chiffres sur les temps de génération du code (build time)

Scaleway.com est généré statiquement. Voici les résultats de la migration vers Next.js sur le temps de génération — ou build — de l’application :

La durée moyenne des générations est passée de 27 minutes à 7 minutes, représentant un gain de 20 minutes par build, soit une réduction de 74 %.

* Nous avons calculé une moyenne sur plusieurs dizaines de générations.

Conclusion

Les sprints de migration de Gatsby vers Next.js ont été des étapes stimulantes pour toute l’équipe durant ces quelques semaines. Cette transition a permis une amélioration significative de notre expérience de développement. Elle a renforcé notre vélocité et notre flexibilité au quotidien grâce à une nouvelle codebase simplifiée et mieux organisée.

Les avantages de cette refonte sont nombreux :

• des temps de build considérablement réduits, permettant des releases plus rapides et une boucle de feedback nettement accélérée ;
• l’adoption de TypeScript, qui prévient efficacement les régressions et renforce la confiance de l’équipe dans le développement et la maintenance de fonctionnalités complexes ;
• une DX améliorée avec Next.js et le tooling associé, qui améliorent le moral de l’équipe;
• une confiance accrue de nos stakeholders qui ont pu observer une augmentation de notre vélocité d’équipe et des features robustes.

Il était important pour nous que chaque membre de l’équipe puisse participer à cette refonte et ajouter sa pierre à l’édifice. Nous sommes tous fiers d’avoir participé à cet effort collectif, et nous sommes convaincus que ces nouveaux outils et cette dynamique renforcée nous aideront à faire progresser Scaleway encore davantage.