L'évolution de Jamstack

À propos de l'auteur

Mathias (Matt) Biilmann est PDG de Netlify une société qu'il a cofondée en 2014 et qui est aujourd'hui l'une des plates-formes de développement Web à la croissance la plus rapide. Il a été …
En savoir plus sur
Mathias
↬

Cela fait cinq ans que j'ai présenté pour la première fois. l'idée de l'architecture Jamstack à SmashingConf à San Francisco 2016, une conférence inspirée par de nombreuses conversations avec des collègues et amis de l'industrie. À ce stade, l'idée de découpler fondamentalement la couche Web frontale de la couche de logique métier principale n'était qu'une tendance précoce, et pas encore une approche architecturale nommée.

Regarder sur Vimeo

Les générateurs de sites statiques émergeaient comme une véritable option pour créer des sites plus grands axés sur le contenu, mais tout l'écosystème autour d'eux était naissant et les principaux générateurs étaient de purs outils open-source sans présence commerciale. Les applications à page unique constituaient la base de certaines applications Web à grande échelle, comme Gmail, mais l'approche typique de leur création était toujours centrée sur le backend.

Avance rapide jusqu'en 2020, Jamstack a atteint le grand public et nous avons vu des millions de développeurs et de grandes marques comme Unilever Nike et PayPal adopter l'architecture. Des initiatives vitales comme le Covid Tracking Project ont pu passer de 0 à 2 millions de requêtes API sur le Jamstack. Des cadres comme Nuxt sont devenus des entreprises commerciales, et nous avons célébré les grandes entreprises publiques comme Microsoft et Cloudflare en lançant les premières offres Jamstack.

À mesure que l'espace commercial s'est réchauffé et que la communauté des développeurs s'est développée, il y a également eu plus de bruit, et nous ' re commence même à tester les limites des meilleures pratiques de Jamstack . Il semble que le moment soit venu à la fois de revoir la vision originale que certains d'entre nous avaient il y a cinq ans et de regarder vers l'avenir ce que les changements dans le paysage technologique signifieront pour l'avenir de l'architecture Jamstack et du Web.

Commençons par

Compilation de l'interface utilisateur

Dans l'architecture Jamstack, l'interface utilisateur est compilée . L'objectif est de faire le bon travail au bon moment – avec une préférence pour faire autant de travail que possible à l'avance. Plusieurs fois, le site entier peut être pré-rendu, peut-être même pas nécessiter un backend une fois déployé.

Decoupled Frontends

Découpler le frontend des services et des plates-formes back-end impose un contrat clair pour la façon dont votre interface utilisateur communique avec le reste de le système. Cette utilise par défaut la simplicité : votre frontend a une surface de contact limitée avec tout ce qui se trouve à l'extérieur de lui-même, ce qui rend moins compliqué la compréhension de la façon dont les changements externes affecteront son fonctionnement.

Extraire les données selon les besoins

tout ne peut pas être prérendu, et l'architecture Jamstack est capable de fournir des applications Web dynamiques et personnalisées ainsi qu'un contenu plus cohérent à l'échelle mondiale. La demande de données depuis le frontend peut alimenter certaines applications riches et dynamiques.

Un bon exemple est le frontend de notre propre Netlify UI qui est elle-même une application Jamstack construite et exécutée sur Netlify. Nous pré-compilons un shell d'application, puis utilisons requêtes asynchrones pour accéder à notre API afin de charger des données sur nos utilisateurs et leurs sites. Que vous utilisiez REST, GraphQL ou WebSockets, si vous précompilez autant de l'interface utilisateur que possible et chargez des données pour offrir à vos utilisateurs une expérience dynamique et personnalisée vous expédiez le Jamstack architecture.

Jamstack en 2021 et au-delà

Il y a plus d'innovation que jamais dans l'écosystème Jamstack. Vous pouvez voir une évolution rapide des services back-end, des outils de développement et des technologies côté client qui se combinent pour permettre aux équipes de développement de créer des expériences pour le Web qui auraient semblé hors de portée il y a seulement quelques années. [19659009] Je veux souligner trois tendances que je vois se dessiner pour les développeurs Jamstack dans un futur proche:

1. Rendu persistant distribué (DPR)

Plus que tout, la simplicité inhérente de Jamstack a rendu le processus de création et de déploiement d'applications Web beaucoup plus facile à raisonner. Les mises à jour de code et de contenu peuvent être pré-rendues sous forme de déploiements atomiques propres et poussées jusqu'au bord, créant de solides garanties de fiabilité et de performances sans avoir à gérer une infrastructure complexe.

un site Web plus grand peut également signifier attendre plusieurs minutes à chaque fois qu'il y a un nouveau déploiement. C’est pourquoi je pense que nous constatons tant d’innovations pour rendre les versions plus intelligentes et plus rapides, en particulier pour les sites et les applications Web plus volumineux. Prenons par exemple la vitesse brute de esbuild le nouveau «compilateur JavaScript extrêmement rapide». Un bundle de production qui peut prendre Parcel ou Webpack plus d'une minute à compiler peut être complété par esbuild en moins d'une seconde . Et des outils de construction comme Vite et Snowpack s'appuient sur des modules ES natifs pour rendre le développement local presque instantané.

Dans l'écosystème React, certains frameworks plus récents comme Remix ou Blitz commencent à s'appuyer davantage sur le "tout exécuter sur un serveur »Approche que nous avons tous connue dans le passé. Il y a un risque de ramener une grande partie de la complexité à laquelle nous avons travaillé pour échapper. Les couches de mise en cache peuvent aider à rendre les applications côté serveur plus performantes, mais les développeurs perdent les garanties des déploiements atomiques qui rendent les applications Jamstack faciles à raisonner.

Blitz semble déplacer le monolithe vers le frontend. Cela peut rendre les applications full-stack exécutables sur des plates-formes Jamstack typiques, mais sans découplage clair entre la couche d'expérience Web et la couche de logique métier principale. Je pense que découpler le frontend du backend est fondamental pour l'approche Jamstack et responsable de débloquer tant de ses avantages.

Ce que je vois prendre de l'ampleur réelle, ce sont les cadres «hybrides» comme Next .js Nuxt.js et SvelteKit qui permettent aux développeurs de mélanger de manière transparente des pages pré-rendues au moment de la construction avec d'autres routes rendues via des fonctions sans serveur. Le défi est que les fonctions sans serveur (bien que certainement évolutives) ont leur propre ensemble d'implications sur les performances .

En fin de compte, je vois la communauté évoluer vers un trio extrêmement puissant qui fournit aux développeurs Jamstack le niveau des requêtes contrôle sur le profil de performance de tout site ou application:

1. Fourniture de pages entièrement pré-rendues au moment de la construction,
2. Livraison de pages dynamiquement via des fonctions sans serveur, ou
3. Création de pages à la demande qui persistent ensuite comme actifs CDN statiques.

Next.js a fait pas mal de travail sur un concept qu'ils appellent Incremental Static Regeneration . L'idée est de garantir des pages hautes performances en combinant des fonctions sans serveur avec différentes stratégies de mise en cache comme Stale While Revalidate . Bien que l'idée de distribuer certaines des versions à une approche à la demande qui inclut toujours de solides garanties de mise en cache soit une technique puissante, il y a un risque de briser les déploiements atomiques dans cette implémentation particulière, et les avantages sont verrouillés dans un cadre singulier, et dans certains cas, un fournisseur.

Chez Netlify, nous voyons beaucoup de promesses dans l'idée de permettre aux développeurs de rendre des pages critiques au moment de la construction, tout en reportant la création d'autres pages (comme les anciens articles de blog, par exemple) uniquement lorsque et s'ils sont demandés. Nous appelons l’approche Rendu persistant distribué ou DPR. C'est une architecture pour les versions incrémentielles qui peut être compatible avec presque tous les frameworks et les générateurs de sites Jamstack, de 11ty à Nuxt en passant par Next.js.

DPR réduira considérablement les temps de construction initiaux pour les sites plus grands, résolvant une critique fondamentale de la génération de sites statiques . Sur Jamstack.org nous avons ouvert une demande de commentaires pour impliquer toute la communauté dans nos efforts pour donner aux développeurs plus d'options sur la façon dont les pages sont rendues tout en adhérant étroitement aux principes qui ont rendu Jamstack si populaire. En donnant un nom à cette architecture et en la peaufinant avec la participation de la communauté, nous pouvons aider les développeurs Jamstack à créer des modèles autour d'elle – quel que soit le cadre.

2. Streaming des mises à jour à partir de la couche de données

Si vous développez des applications Web, vous avez probablement suivi l’évolution des bibliothèques de gestion d’états, les développeurs ayant construit des interfaces Web de plus en plus complexes à l’aide d’outils tels que React, Vue et Svelte. Mais la gestion des états a été en grande partie une préoccupation dans le navigateur et en mémoire. Chaque onglet du navigateur a essentiellement son propre état, mais il peut être assez complexe de relier l'état du navigateur local de votre application aux services de données qui l'alimentent.

Heureusement, cela s'améliore à mesure que de plus en plus de services prennent en charge maintenant abonnements aux données en temps réel . Hasura OneGraph et Supabase offrent tous cette capacité et je m'attends à voir une adoption plus large chez tous les fournisseurs car les magasins de données sous-jacents sont mis en cache et distribués au Edge pour des performances globales rapides. Prenez les API en pleine expansion de Twillio: elles offrent désormais non seulement la vidéo en continu mais aussi des «pistes de données» en continu, qui peuvent être utilisées pour créer des applications de collaboration complexes qui restent continuellement synchronisées entre les participants.

Enfin, les nouveaux fournisseurs sont émergeant de ces données agrégées dans les services back-end Que vous utilisiez ou non GraphQL comme langage de requête, il est vraiment convaincant d’imaginer la puissance de la connexion de votre interface utilisateur à un flux standard unique de mises à jour provenant de plusieurs API sous-jacentes.

3. La collaboration avec les développeurs se généralise

Le Jamstack est construit sur un flux de travail Git – une approche qui s'adapte très bien aux grandes équipes de développement. Mais à l'avenir, nous commencerons à voir comment ces outils traditionnellement axés sur les développeurs vont s'étendre pour impliquer tout le monde dans l'entreprise: les développeurs, bien sûr, mais aussi les rédacteurs, les éditeurs, les concepteurs et les experts en référencement. , vous avez tendance à penser aux modifications synchrones – les multiples curseurs qui volent autour d'un document Google, par exemple. Nous voyons ce style de collaboration en direct arriver aux outils CMS comme Sanity et aux outils de conception comme Figma. Mais tant de travail se déroule souvent de manière asynchrone, et les non-développeurs n'ont traditionnellement pas apprécié les outils puissants que les développeurs utilisent pour créer des branches, mettre en scène et fusionner de manière transparente les modifications avec discussion collaborative attachée à chaque pull request .

Au début du Jamstack, des outils CMS intelligents basés sur git sont apparus pour aider les non-développeurs à gérer du contenu comme du code – peut-être sans même savoir que chaque changement qu'ils apportaient était git-engagé, tout comme un développeur travaillant à partir du terminal. Nous commençons maintenant à voir de nouveaux outils s'attaquer aux modifications des pages visuelles d'une manière qui reste compatible avec les générateurs de sites Jamstack populaires tels que Gatsby et Next.js. Tout cela abaisse la barre de la collaboration pour les non-développeurs et nous ne ferons que voir cette tendance s'accélérer.

Et il n'y a pas que des non-développeurs qui se joignent à la collaboration: des intégrations profondes entre les outils apportent des contributions plus automatisées à nos flux de travail de développement, de création et de déploiement. Il suffit de parcourir l'historique des commentaires sur une demande d'extraction GitHub pour voir combien d'outils sont désormais intégrés pour exécuter des tests automatisés et détecter les erreurs avant leur déploiement.

Les mises à jour de la documentation de Netlify, par exemple, ne sont pas seulement liées à nos normes de code , ils sont également conformes à nos normes de contenu, ce qui nous permet de rester cohérent avec notre guide de style pour le vocabulaire, la langue et le phrasé. Les équipes peuvent désormais facilement lier les budgets de performance et les normes de référencement à chaque déploiement, toujours avec des alertes et des journaux directement liés aux problèmes de GitHub.

Je m'attendrais à voir ce genre d'intégrations exploser dans l'année à venir, permettant à un flux de travail basé sur git de sous-tendre non seulement les changements de code, mais également le contenu, les données et les actifs de conception – vous l'appelez. Des interfaces conviviales dans ces flux de travail Git permettront à davantage de contributeurs de commenter, de valider et de collaborer et d'intégrer davantage les outils de productivité des développeurs dans le courant dominant.

Activation des cas d'utilisation évolutifs et dynamiques

Alors que Jamstack reste fidèle aux concepts de base du découplage du frontend du backend et la maintenance des déploiements immuables et atomiques, les nouvelles stratégies de construction et les primitives de calcul ont le potentiel de débloquer des sites à très grande échelle et des applications Web dynamiques en temps réel.

Les développeurs Jamstack – et maintenant des équipes Web entières, des spécialistes du marketing, et les chefs de produit – ont beaucoup à attendre dans cet espace.

Lectures et références complémentaires

( vf, il)