Skip to content

Latest commit

 

History

History
117 lines (72 loc) · 8.89 KB

2017-03-13-jamstack.html.md

File metadata and controls

117 lines (72 loc) · 8.89 KB
date slug title description image page_title page_emphasis page_class
2017-03-13
jamstack
Introduction à JAMstack : JavaScript, API et Markup
Quels sont les avantages et bonnes pratiques dans la génération de sites statiques. Pourquoi cette solution est meilleure en terme de performance, sécurité et coûts par rapport aux classiques CMS comme wordpress et Drupal
Architecture de développement Web moderne
JavaScript côté client, API réutilisable et Markup pré-construit
good-practice

Prenons la définition de wikipédia pour stack technique : un ensemble de logiciels ou composants nécessaires pour créer une plate-forme complète. Si l’on examine 2 secondes mon profil de développeur front-end sur stackshare on remaque que je travaille avec avec des outils du modernes comme Slack, GitHub ou encore Stripe.

Au début des années 2000 la stack populaire ressemblait à LAMP ou encore WAMP. Pour avoir un site internet il fallait une stack complète avec Linux, Apache MySQL et php. Le web a changé, JavaScript a évolué. Au XXIème siècle il est possible d’avoir de nouvelles solutions comme la JAM stack.

Définition de JAM stack

JAM stack logo

Votre projet de site web est considéré comme JAM stack s’il respecte 3 critères :

JavaScript

Toute programmation dynamique du cycle de requête / réponse est gérée par JavaScript, exécutée entièrement sur le client.
Cela peut être n’importe quel librairie, framework front-end ou encore JavaScript vanilla.

API

Les processus côté serveur ou les actions de base de données sont abstraites en API réutilisables, accessibles via HTTP avec JavaScript.
Cela peut être des API personnalisées ou utiliser des services tiers.

Markup

Le balisage HTML doit être pré-construit au moment du déploiement, généralement à l’aide d’un générateur de site pour les sites de contenu ou un outil de création d’applications Web.

À partir de quand un projet n’est pas développé en JAM stack ?

Tout projet qui repose sur un couplage fort entre le client et le serveur n’est pas construit en JAM stack. Exemple :

  • Un site développpé avec un CMS serveur comme WordPress, Drupal, Joomla, ou Squarespace.
  • Une application web monolithique développpé en Ruby, Node, ou tout autre langage backend.
  • Une Single Page Application utilisant un rendu isomorphique pour construire des vues sur le serveur à l’exécution.

Pourquoi utiliser une JAM stack ?

Une meilleure performance

Pourquoi attendre la construction des pages à la volée quand vous pouvez les générer lors de l’étape du déploiement ?
Quand il faut minimiser le temps d’attente pour le téléchargment du premier byte, rien n’égale des fichiers pré-construits servis par un CDN.

Sécurité accrue

Avec une architecture serveur éclatée en microservices et abstraite en APIs, les zones d’attaques sont réduites.
Vous pouvez également tirer parti de l’expertise métier en utilisant des services tiers spécialisés.

Plus besoin de mettre à jour votre faille critique de Drupal car il n’y a pas de base de données. Les certificats SSL sont également faciles à installer et disponibles gratuitement grâce à des services comme LetsEncrypt.

Moins cher, plus évolutif

Quand votre déploiement consiste à rassembler des fichier pour être distribués depuis n'importe où, l’elasticité d’une plateforme consiste à servir ces fichiers depuis d’autres endroits.
Les CDN sont parfait pour cela, et possèdent de base des solutions pour mettre à l’echelle rapidement.

Une meilleure DX

Certains d’entre vous sont familers avec l’UX ou User eXperience ? Sachez qu’il existe aussi la Developer eXperience.

La perte du couplage et la séparation des responsabilités permettent un développement et un débogage plus ciblés. Les générateurs de sites suppriment la nécessité de maintenir une stack distincte pour le contenu et une autre pour le marketing.

Bonnes pratiques

Lors de la construction de projets JAM stack, vous pouvez exploiter le meilleur de cette solution si vous respectez quelques pratiques exemplaires.

Hébergement sur un CDN

Étant donné que les projets JAM stack ne s’appuient pas sur du code côté serveur, ils peuvent être distribués au lieu de vivre sur un seul serveur. Servis directement depuis un CDN les applications web la vitesses et des performances qui ne peuvent pas être battus.
Le plus de votre application, vous pouvez pousser vers le bord, le mieux l'expérience utilisateur.

TOUT est historisé avec git

Avec un projet JAM stack, tout le monde devrait être capable de git clone, installer toutes les dépendences avec une procédure standart (comme npm install), et être prêt à lancer le projet localement.
Pas de base de données à cloner, aucune complexité dans l'installation. Cela réduit la frustrastion des contributeurs, et simplifie la gestion des environements de test et de staging.

Vous pouvez facilement permettre à d’autres personnes de contribuer avec des solutions comme prose.io

Outils du futur

Profitez du monde des outils de construction modernes.
Cela peut ressembler à une jungle pour à l’installation et les technologies évoluent rapidement, mais vous aurez envie d'utiliser les standards web de demain sans attendre les navigateurs de demain.

Actuellement cela signifie utiliser Babel, PostCSS, Webpack, & leurs amis.

Builds automatiques

Comme le HTML de la JAM stack est pré-construit, les modifications de contenu ne seront pas visibles tant que vous n'aurez pas exécuté une autre build. Automatiser ce processus vous permettra d'économiser beaucoup de maux de tête. Vous pouvez le faire vous-même avec des webhooks, ou utiliser une plate-forme de publication qui inclut ce service automatiquement.

Déployement atomiques

Au fur et à mesure que les projets JAM stack grandissent, de nouvelles modifications peuvent nécessiter le redéploiement de centains de fichiers. Le téléchargement de ces derniers un par un peut provoquer un état incohérent avant la fin du processus.
Vous pouvez éviter cela avec un système qui vous permet de faire des “déploiements atomiques”, où aucun changement ne sera mis en ligne avant que tous les fichiers modifiés n’aient été téléchargés.

Invalidation du cache instantannée

Lorsque le cycle : construction > déploiement terminé devient régulier, vous devez savoir que lorsqu'un déploiement est en production, il est réellement en production.
Éliminez tout doute en vous assurant que votre CDN peut gérer des purges de cache instantanées.

What’s next ?

J’ai abandonné wordpress depuis 2014 pour migrer vers middleman. Je pense avoir eu raison car en 2017 l’industrie du web commence à s’interesser à ce type de solutions, même pour des sites à fort traffic comme smashing magazine.

@smdly We’re moving to @Netlify, and the JAM stack. https://t.co/38Lg04VpwC

— Smashing Magazine (@smashingmag) 9 mars 2017
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

Pour votre prochain projet JAM Stack je vous conseille d’essayer Phenomic, un générateur de site statique basé sur l'écosytème React et Webpack.