Mais enfin, qu'est-ce que la JAMstack ?

Bienvenue dans le futur du développement web. Voilà une jolie punchline de publicitaire qui pourrait résumer ce qu’est la JAMstack. Le premier réflexe lorsque l’on croise un terme de ce type c’est d’essayer une traduction littérale. Si vous parlez un peu anglais « jam » c’est de la confiture. Vous ne voyez pas le rapport avec le développement web ? Soyez rassuré si vous préférez la compote, car la JAMstack n’a absolument aucun rapport avec la confiture. JAMstack vient de JavaScript, API, et Markup généré par avance.

Ne vous inquiétez pas je vais tout vous expliquer, pas la peine de faire cette tête.

Concrètement c’est quoi la JAMstack ?

Commençons par définir le terme de « stack ». Ce terme désigne dans notre cas un ensemble de technologies du web utilisées pour créer des sites et applications web. L’ensemble de ces technologies peut s’abréger par JAM.

JavaScript : toute la partie dynamique du site/app est gérée par JavaScript. Même s’il est possible de tout faire avec du JavaScript vanilla, généralement, le JavaScript utilisé est une librairie de type React ou Vue. Mais au final, peu importe la librairie, tout ça n’est que du JavaScript. APIs : là ça se complique. Si vous voulez en savoir plus sur les APIs, lisez mon article sur le sujet. Pour résumer à notre cas d’usage, une API représente ici un point d’accès vers un service back-end ou une base de donnée. Ce point d’accès va permettre à notre site de récupérer des données brutes afin de les traiter et d’augmenter la dynamique du site. Cette partie back-end peut être développée par vos soins ou vous pouvez tout aussi bien utiliser des SaaS. Cette API peut être accessible via REST ou GraphQL. Markup : c’est tout le code responsable de l’ossature et de la présentation du site : le HTML et le CSS. Ce code est généré par avance par un générateur de site statique ou générateur de web-apps.

C’est bon, maintenant vous voyez un peu plus ce qu’est la JAMstack.

La JAMstack et son architecture sans serveurs.

La JAMstack a une caractéristique majeure : celle de ne pas dépendre d’un serveur web.

Ah ah vous vous dites que je marche sur la tête n’est-ce pas ? Les serveurs web sont un élément central de tout site web. Pour le web traditionnel, c’est tout à fait vrai. Mais pour la JAMstack c’est différent ! Pour la JAMstack les serveurs web ne sont qu’un élément accessoire. Important à certains égards, mais accessoire tout de même. Pour imager la chose, dans une architecture traditionnelle, le serveur c’est le corps humain. C’est la base de la vie, si vous n’avez pas de corps, vous n’êtes pas vivant. Dans une architecture serverless, les serveurs sont vos vêtements, vos accessoires comme votre montre, votre bonnet phrygien, etc. La JAMstack quant à elle est votre corps. Sans JAM vous êtes mort. Par contre, sans vêtements, tout va bien. Vous aurez sans doute un peu froid et ne serez pas très à l’aise en public, mais vous survivrez jusqu’à remettre des vêtements. J’espère que cette image vous aide à voir la différence. Gardez-la dans un coin de votre tête si vous commencez à vous embrouiller.

Bref, l’architecture de base de la JAMstack c’est du serverless. Votre site est généré par avance. Il peut être stocké sur ce que l’on appelle des CDN qui sont des sortes d’hébergeurs de contenu statique. J’en parle plus en détail dans mon article de présentation sur Gatsby, juste ici, si vous voulez en savoir plus.

Je vais ici insister sur un point : une architecture sans serveur ne veut pas dire qu’il n’y a aucun serveur impliqué dans le fonctionnement de votre site. Simplement qu’il n’y a aucun serveur au centre de votre architecture. Rappelez-vous de mon analogie. Dans la JAMstack les serveurs ont une utilité en tant que microservices pour permettre à votre JavaScript de se connecter à des APIs et ainsi donner à votre site toutes les fonctionnalités dont vous pouvez rêver.

La JAMstack et le rendu à la génération vs à l’exécution

Comme je vous l’ai dit, le Markup de votre page est généré à l’avance. Traditionnellement une page est générée à l’exécution de la page par un client. Cette génération se fait traditionnellement par le serveur. Pour un client ça va, mais imaginez pour 10 000 clients … ! Même avec un système de cache en place sur le serveur ça demande quand même un minimum de travail. Ici en revanche, la page n’est plus générée au moment où un client la demande, mais bien à l’avance. Autrement dit avant même que qui que ce soit ne demande à consulter votre site. Quel intérêt ? On en parle dans la prochaine section.

Quel est l’intérêt d’utiliser la JAMstack ?

Les raisons pour utiliser la JAMstack sont nombreuses. Voici un bref récapitulatif des principaux avantages. **De meilleures performances **: Le plus gros de votre site est généré par avance, la question ici est de servir chaque client avec ce contenu déjà créé. Que vous ayez un ou mille utilisateurs, ça ne change pas grand-chose, votre page n’est générée qu’une fois. Bien entendu, cela ne veut pas dire que votre contenu est fixe, car vous utilisez d’une part des APIs qui peuvent retourner des infos en temps réel, mais aussi parce que dès que le contenu en lui-même va changer, la page va se générer à nouveau dans son coin. Le gros du travail se fait donc à la génération.

Moins cher : votre serveur n’étant plus l’élément central et vos fichiers étant généré par avance, un contenu statique est dérisoire, voire gratuit, dans de nombreux cas. Je vous invite à consulter les tarifs de Netlify, ZEIT Now et AWS Amplify. Rien à voir avec les couts classiques d’hébergement. Il se murmure même que cela pourrait représenter une baisse de 75% des couts d’infrastructures. C’est du moins ce qu’avait présenté Amazon dans son AWS Roadshow 2019 en comparant les différentes architectures. Mais attention ! Étant donné que vous utilisez des APIs, l’utilisation de SaaS peut vite faire grimper la facture … Un développement maison est parfois à privilégier.

Plus sécurisé: difficile de s’attaquer à des pages statiques n’est-ce pas ? Ici les entrées possibles pour les attaquants se font au niveau de chaque microservice. Néanmoins chaque microservice étant indépendant dans son fonctionnement, une attaque sur l’un ne viendra pas se propager à tous les autres. Avec un serveur monolithique traditionnel, la surface potentielle pour mettre à mal votre serveur est bien plus grande et surtout, si votre serveur tombe, tout tombe avec lui.

Un développement plus rapide : bien plus facile de créer et gérer des microservices que de créer et gérer un bloc monolithique où chaque partie est difficilement modifiable sans affecter l’ensemble de votre infrastructure. Il est ainsi beaucoup plus rapide de développer de nouvelles fonctionnalités et maintenir les existantes.

Comment utiliser la JAMstack ?

La JAMstack vous intéresse ? Même si vous pouvez tout coder à la main, je vous recommande vivement de vous tourner vers des outils déjà existants et qui vont vous permettre d’éviter de réinventer la roue pour la 100e fois. Je vais vous parler ici d’outils React étant donné que c’est la technologie que j’utilise le plus.

Vous avez des générateurs de sites statiques comme Hugo, Jekyll, GitHub Pages, qui vous permettent de créer des sites statiques facilement tout en utilisant les dernières technologies. Cependant, vous allez vite voir les limites de ce type de système dès que vous souhaiterez inclure des APIs pour créer du contenu dynamique.

Mon conseil est de vous tourner vers des outils hybrides comme Gatsby ou Next.js qui vous permettent de réaliser un peu tout ce qui peut vous passer par la tête, des sites statiques ou dynamiques et applications web complexes. Chacun de ces deux systèmes fonctionne différemment. Tous deux sont des systèmes très agréables à utiliser et novateurs. Je vous invite à les tester sans attendre. Si vous avez peur qu’il ne s’agisse de systèmes peu fiables, sachez que de très nombreuses entreprises d’envergure internationale utilisent ces systèmes. Alors pourquoi pas vous ?

C’est tout … pour le moment.