En 2012, le site Internet dédié au financement de la campagne de B. Obama devait faire face à un triple défi :
- Absorber le trafic de 18 millions de visiteurs uniques sans dégradations des performances,
- Disposer d'un gilet pare-balle triple épaisseur pour déjouer les tentatives de DDoS (attaques visant à mettre le site HS, menées par des opposants à sa candidature),
- Proposer un système de paiement en ligne fiable pour collecter + de 4 millions de dons, représentant au total 250 millions de $.
A votre avis, quels outils ont été choisis pour le réaliser ?
WordPress ? Symfony ? Drupal ?
Non.
Le site est seulement composé de pages HTML statiques, hébergées sur Amazon (AWS S3) et distribuées à travers le monde sur des serveur de contenu.
Elles ont été créées automatiquement par Jekyll, un générateur de site statique.
Statique : rien ne bouge (ou presque)
Un retour aux pages HTML statiques comme on les créait il y a 25 ans avec Dreamweaver ? C'est ça l'innovation ?
Pas vraiment !
L'innovation consiste à séparer ce qui évolue lentement et ce qui doit réagir en temps-réel. C'est le principe des architectures "JAM" (Javascript API Markdown).
Avec une architecture classique, votre navigateur Internet adresse ses demandes à un serveur qui va calculer en temps-réel la page à retourner.
Avec une architecture JAM, on va différencier le traitement des demandes :
- en servant ultra vite celles qui concernent les pages statiques, dont le contenu ne dépend pas d'une action de l'utilisateur. On va vite car elles ont été construites par anticipation et diffusées sur des serveurs proches des utilisateurs (“CDN”),
- et en calculant en temps-réel le contenu dynamique qui dépend de données renseignées par l'utilisateur. Par exemple pour prendre en compte un paiement par carte bancaire. Ces calculs seront réalisés par des modules séparés qui fournissent une API (= un moyen d'interagir avec eux).
En optimisant l'architecture de cette façon, le temps d'affichage du site de B. Obama s'est considérablement amélioré. Et ce gain de performance (60% + rapide que la plateforme de fundraising initialement développée) s'est traduit par une augmentation des dons (+14%).
Car personne n'aime poireauter devant une page qui met trop de temps à se charger.
On ne créé pas les pages statiques à la main, mais grâce à un générateur (SSG = Static Site Generator). Le SSG va aller piocher dans les sources de contenu tout ce qui est nécessaire pour construire les pages.
On déclenche cette construction à chaque fois que l’on veut modifier le contenu du site : tous les jours, voire toutes les heures si besoin. Une fois terminée, le site est mis à jour avec les pages nouvellement générées, sans interrompre le service.
Parmi les SSG qui ont la côte en ce moment, citons Gatsby, Hugo, Eleventy, Next, ... On en recense plusieurs dizaines , et j'en ai même codé un en Python pour un client qui avait un besoin spécifique sur le traitement des images.
Mais comment intègre-t-on le service de paiement dans tout ça ?
API et services spécialisés
Après avoir navigué sur les différentes pages (qui s'affichent vite), on arrive donc au bouton fatidique "Faire un don".
A partir de ce moment s'affiche le formulaire de saisie d'un montant et d'un numéro de CB. On bascule vers le chemin dynamique, puisqu'on ne connaît pas à l'avance ces données.
L'idée est de conserver l'objectif d'optimisation : on transmet à l'API de paiement ce qui est strictement nécessaire à son fonctionnement, sans lui demander de créer des pages.
On se focalise sur les enjeux de sécurité en chiffrant les données échangées, et sur la détection de fraudes. Pas sur la présentation.
C'est l'autre versant des architectures JAM : l'utilisation de services spécialisés sur un domaine, auxquels on accède en s'échangeant des données d'une autre nature que des pages internet.
Tout comme les générateurs statiques, on observe ces derniers temps une profusion d'offres :
- Besoin d'un service paiement ? Stripe, Paypal, ChargeBee, Recurly, Trolley, Braintree.
- Besoin d'un formulaire ? TypeForm, FormKeep, Netlify Forms, Formspree, Formium,
- Une base de données pour stocker des articles ? ContentFul, ButterCMS, Prismic, Sanity, etc. CMS Wire recense actuellement 34 headless CMS pour ça !
Pour utiliser ces services à partir des pages statiques, il faut y embarquer du code Javascript. Parfois dans des proportions importantes : le site de financement de la campagne de B. Obama comportait environ 4000 lignes pour gérer l'API REST avec le service de paiement.
La JAM Stack : l'architecture qu'il faut pour mon projet ?
Les architectures JAM Stack sont dans l'air du temps. Certains y voir l'avenir d'internet, d'autres une forme de retour en arrière.
C'est en tout cas une architecture qui insufle une vague (tsunami ?) de nouveaux produits, dont de nombreux sont open-source.
Cette architecture convient bien aux sites qui comportent une large face "publique" : journaux en ligne, e-commerce, places de marchés par exemple. Les pages statiques permettent des performances élevés, une excellente sécurité, et un bon moyen de figurer en bonne position dans les recherches google (SEO).
Exemples :
C’est une architecture qui se prête aussi très bien aux catalogues en ligne ou au sites de documentation : https://vuepress.vuejs.org/guide/#how-it-works
Elles incitent à la modularité et à l'utilisation de services tiers pour réaliser les parties dynamiques. On gagne du temps avec ces services spécialisés, en contrepartie d'un effort d'intégration (et d'un coût d'abonnement à ces services).
Exemples :
- https://www.easyship.com avec un calculateur dynamique de prix d'expédition
- https://www.smashingmagazine.com: du contenu statique, mais aussi une billetterie et de la vente en ligne
En revanche ce sont des architectures inadaptées :
- aux outils 100% dynamiques : si le site requiert un passage obligé par une authentification login / mot de passe, il n'y a rien à générer statiquement !
- aux services dont le contenu est généré par leurs utilisateurs : réseau social, forum de discussion.
