Abonnez-vous pour recevoir des notifications sur les nouveaux articles :

Cloudflare Pages passe au full-stack

2021-11-17

Lecture: 6 min.
Cet article est également disponible en English, en Deutsch, en 日本語 et en 简体中文.

Lorsque nous avons annoncé la disponibilité générale de la solution Cloudflare Pages en avril, nous vous avons promis qu'il ne s'agissait là que du début. Le parcours de notre plate-forme a commencé par la prise en charge des sites statiques incluant une légère couche de fonctionnalités dynamiques, comme la définition de redirections et d'en-têtes personnalisés. Toutefois, nous souhaitions vous offrir encore plus de puissance, à vous et à vos équipes, afin de vous permettre de développer l'inimaginable. Nous envisagions un avenir au sein duquel l'intégralité de votre application (front-end, API, stockage, données) pourrait être déployée à l'aide d'un commit unique, facilement testable pendant la préproduction et ne nécessitant qu'une simple fusion lors du déploiement en production. Aujourd'hui, dans l'esprit de la « Full Stack Week », nous vous offrons les outils nécessaires à la réalisation de cet objectif.

Cloudflare Pages Goes Full-Stack

Bienvenue dans l'avenir. Nous nous réjouissons de vous annoncer que la solution Pages constitue désormais une plate-forme full-stack, soutenue par Cloudflare Workers !

Mais comment ?

La solution Pages fonctionne de la même façon qu'elle l'a toujours fait : rédigez votre code, effectuez un « git push » vers votre fournisseur Git (nous prenons désormais en charge GitLab !) et nous déploierons l'intégralité de votre site pour vous. L'unique différence réside dans le fait que votre infrastructure front-end ne sera plus la seule à tirer parti de Cloudflare Workers : votre back-end s'appuiera également dessus pour déployer des fonctions serverless.

L'intégration que vous attendiez

Cloudflare Workers propose un environnement d'exécution serverless qui vous permet de créer des applications totalement nouvelles ou d'augmenter des produits déjà existants, sans configurer ni entretenir d'infrastructure. Avant aujourd'hui, il était possible de connecter des Workers à un projet Pages, en installant Wrangler et en déployant manuellement un Worker en écrivant votre application à la fois dans Pages et Workers. Toutefois, le fait que ce soit « possible » ne nous suffisait pas : nous souhaitions mettre au point une solution qui serait comme une seconde nature pour vous et vous permettrait d'ajouter des fonctionnalités dynamiques à votre site sans y repenser à deux fois.

Fonctionnement

En utilisant la convention de système de fichiers de votre dépôt et en exportant un ou plusieurs handlers de traitement de fonction, Pages peut s'appuyer sur Workers pour déployer des fonctions serverless en votre nom. Pour commencer le processus, il vous suffit d'ajouter un répertoire « ./fonctions » à la racine de votre projet et d'exporter un handler de fonction dans un fichier JavaScript ou TypeScript. Imaginons, par exemple, que vous disposiez d'un fichier nommé « hello.js » au sein de votre répertoire « ./fonctions » et que ce fichier contienne le code suivant :

La commande « git commit » entraînerait le déploiement d'une nouvelle version exécutable Pages sur votre site dynamique ! Au cours du pipeline de version, Pages parcourt votre répertoire, en faisant correspondre les noms de fichiers aux URL par rapport à la structure de votre dépôt.

// GET requests to /filename would return "Hello, world!"
export const onRequestGet = () => {
  return new Response("Hello, world!")
}

// POST requests to /filename with a JSON-encoded body would return "Hello, <name>!"
export const onRequestPost = async ({ request }) => {
  const { name } = await request.json()
  return new Response(`Hello, ${name}!`)
}

Sous le capot, Pages génère des Workers incluant l'ensemble de vos informations de routage et de vos fonctionnalités depuis la source. Les fonctions prennent en charge le routage à l'aide de chemins profondément imbriqués, la correspondance par caractères génériques, l'utilisation d'intergiciels pour traiter certaines tâches, telles que l'authentification et la gestion des erreurs, et plus encore ! Pour démontrer l'intégralité de notre proposition, nous avons publié un article de blog qui présente en détail un exemple d'application full-stack.

Vous laisser faire ce que vous faites le mieux

La nouvelle fonctionnalité full-stack de Pages permet de préserver la simplicité de l'expérience côté développeur malgré la montée en complexité de votre site. Vous pouvez continuer à profiter du flux de travail que vous connaissez et appréciez, tout en débloquant de nouveaux axes de profondeur pour votre site.

Développez en toute fluidité

À l'instar du traitement des versions exécutables et des déploiements pour vos sites statiques (à l'aide des commandes « git commit » et « git push »), nous nous chargeons de déployer vos fonctions à votre place, de manière automatique. Tant que votre répertoire suit la structure appropriée, Pages identifie et déploie vos fonctions sur notre réseau en même temps que votre site.

Définir vos liaisons

Lors du déploiement de vos Workers sur Pages, les liaisons constituent une grande partie du caractère full-stack de votre application**.** Nous sommes impatients de déployer sur Pages l'ensemble des liaisons que vous utilisiez auparavant avec les Workers normaux !

  • Espace de noms KV : notre solution de stockage clé-valeur serverless et accessible partout dans le monde. Pages vous permet d'intégrer votre application à n'importe quel espace de noms KV défini par vos soins au sein du tableau de bord Workers de votre projet Pages.

  • Espace de noms Durable Object : notre primitive de coordination à forte cohérence qui simplifie grandement la connexion de WebSockets, le traitement des états et le développement d'applications entières. Comme pour KV, vous pouvez définir vos espaces de noms dans le tableau de bord Workers et faire votre choix parmi cette liste au sein de l'interface de Pages.

  • R2 (prochainement !) : notre solution de stockage d'objets compatible S3 qui réduit à zéro les frais de sortie.

  • Variable d'environnement : une valeur injectée, accessible par vos fonctions et stockée sous forme de texte clair. Vous pouvez définir vos variables d'environnement directement au sein de l'interface de Pages au moment de la compilation et de l'exécution, et ce à la fois pour vos environnements de production et de prévisualisation.

  • Secret (prochainement !) : une variable d'environnement chiffrée, impossible à visualiser par Wrangler ou une quelconque interface de tableau de bord. Les secrets se révèlent particulièrement intéressants pour héberger les données sensibles, notamment les mots de passe et les jetons d'API.

Prévisualisation des déploiements : une fonction désormais disponible pour votre back-end lui aussi

Le déploiement de vos fonctions serverless vous permettra de continuer à profiter de la simplicité des procédures de collaboration et de tests, comme par le passé. Avant de mettre votre projet en production, vous pouvez facilement déployer ce dernier au sein d'un environnement de prévisualisation afin d'observer vos modifications. Même avec vos fonctions, Pages vous permet de conserver un historique des versions de vos commits, sous la forme d'une URL unique pour chacun d'eux. La collecte de commentaires s'en trouve ainsi facilitée, qu'ils proviennent d'un de vos collègues développeurs, d'un chef de projet, d'un concepteur ou d'un spécialiste du marketing ! Vous pouvez également bénéficier des mêmes privilèges infinis en matière de préproduction que ceux dont vous profitiez pour les sites statiques, à l'aide d'une URL cohérente reflétant les dernières modifications.

Développez et effectuez vos prévisualisations à l'échelon local également

Nous réalisons toutefois que le processus de développement et de déploiement de chaque petite modification afin d'observer ces dernières en préproduction peut parfois se révéler fastidieux en cas d'itération rapide. La dernière version de notre CLI Wrangler vous permet désormais de développer des applications Pages full-stack. Grâce à Miniflare, vous pouvez exécuter l'intégralité de votre application à l'échelon local, avec prise en charge des secrets, des variables d'environnements et de KV (la solution Durable Objects sera bientôt prise en charge !). Faites pointer Wrangler vers un répertoire de ressources statiques ou connectez-vous en toute transparence à vos outils existants :

Nous n'en sommes qu'aux débuts de l'intégration de Pages à Wrangler. Restez à l'écoute pendant que nous continuons à améliorer l'expérience côté développeur.

# Install wrangler v2 beta
npm install wrangler@beta

# Serve a folder of static assets
npx wrangler pages dev ./dist

# Or automatically proxy your existing tools
npx wrangler pages dev -- npx react-scripts start

Que pouvez-vous faire d'autre ?

Tout ce que vous pouvez faire avec HTTP Workers à l'heure actuelle !

Lors du déploiement d'une application Pages avec fonctions, Pages compile et déploie des Workers de première classe en votre nom. Cette procédure implique qu'aucune perte de fonctionnalité ne vient ternir le déploiement d'un Worker au sein de votre application Pages et que l'opération n'offre que de nouveaux avantages !

Intégration immédiate à SvelteKit

SvelteKit est un framework web permettant de développer des applications Svelte. Conçu et entretenu par l'équipe Svelte, il constitue la solution incontournable des utilisateurs de Svelte pour l'ensemble de leurs besoins en matière d'applications. Le SvelteKit permet aux utilisateurs de développer immédiatement des projets dotés de back-ends d'API complexes.

À l'heure actuelle, les projets SvelteKit peuvent intégrer et configurer le package « @sveltejs/adapter-cloudflare ». Une fois cette opération effectuée, le projet peut être ajouté à Pages. Il sera alors prêt pour son premier déploiement ! Grâce à Pages, votre projet SvelteKit peut se déployer avec des points de terminaison d'API et une prise en charge intégrale du rendu côté serveur. Mieux encore, le projet dans son ensemble (incluant les points de terminaison d'API donc) peut également profiter des avantages liés à la prévisualisation du déploiement ! Même en soi, il s'agit là d'une victoire énorme pour les projets avancés qui se reposaient autrefois sur l'adaptateur Workers. Consultez cet exemple afin d'observer l'adaptateur SvelteKit pour Pages en action !

Utilisation du rendu côté serveur

Vous êtes désormais en mesure d'intercepter toutes les requêtes destinées à votre projet Pages. Cette possibilité implique que vous pouvez définir une logique Workers qui recevra les URL entrantes. Plutôt que de diffuser du HTML statique, votre Worker rendra ainsi de nouvelles réponses HTML, dotées de données dynamiques.

Une application dotée d'une page de produit, par exemple, peut définir un unique fichier « product/[id].js » qui recevra le paramètre « id », récupérera les informations sur le produit à partir d'une liaison Workers KV et générera une réponse HTML pour la page. Par rapport à l'approche d'un site statique en matière de génération, il s'agit là d'un moyen plus succinct et facile à entretenir au fil du temps, car vous n'avez pas besoin de créer une page HTML statique par produit au moment de la compilation… soit un nombre potentiel de pages pouvant se compter en dizaines, voire en centaines de milliers !

Vous disposez déjà d'un Worker ? Nous avons ce qu'il vous faut !

Si vous disposez déjà d'un Worker que vous souhaitez transférer vers Pages, afin de bénéficier des avantages de notre plate-forme en matière d'expérience côté développeur, notre annonce d'aujourd'hui vous permet justement de procéder à cette opération. Il suffit à votre version exécutable de générer un module ES Worker nommé « _worker.js » dans le répertoire de sortie de votre projet, d'exécuter vos commandes git de déploiement et nous nous chargerons du reste ! Ce processus peut se révéler particulièrement avantageux pour vous, si vous êtes auteur de framework ou si vous travaillez sur un scénario d'utilisation plus complexe qui ne suit pas la structure de fichiers que nous avons fournie.

Essayez la solution gratuitement, pendant une durée limitée

Nous nous réjouissons de lancer aujourd'hui notre bêta ouverte, afin que tous puissent essayer notre solution, sans coût supplémentaire sur votre offre Cloudflare. Si nos solutions présentent toujours des limites en place à l'heure actuelle, cette période de bêta nous permettra d'en apprendre plus sur la manière dont vous et vos équipes déployez les fonctions au sein de vos projets Pages. Pour le moment, nous vous encourageons à libérer votre créativité et à développer ce site auquel vous pensez depuis longtemps, sans vous soucier d'une quelconque facturation.

Dans quelques mois, lorsque nous annoncerons la mise en disponibilité générale, vous pouvez vous attendre à ce que notre facturation ressemble à celle de notre offre groupée Workers. Après tout, la solution ne repose que sur des Workers !

Prochainement…

Si l'annonce concernant le lancement présent prend uniquement la forme d'une bêta ouverte, nous vous avons préparé un programme passionnant pour les mois et les semaines à venir. Nous souhaitons améliorer l'expérience simple et rapide de Pages que vous connaissez déjà côté développeur en ajoutant la prise en charge de la journalisation intégrée et de nouveaux outils d'analyse pour les fonctions que vous avez déployées.

Nous comptons ensuite élargir notre prise en charge de première classe à la prochaine génération de frameworks front-end. Comme nous l'avons montré avec SvelteKit, la capacité de Pages à déployer du code statique et dynamique de manière conjointe et transparente offre des performances imbattables pour l'utilisateur final et facilite la tâche des développeurs. D'ailleurs, nous avons hâte de rendre ces possibilités accessibles à davantage de personnes. Fans de frameworks et de technologies similaires, comme NextJS, NuxtJS, React Server Components, Remix, Hydrogen, etc., restez à l'écoute de ce blog pour de nouvelles annonces. Ou mieux encore, rejoignez-nous et aidez-nous à concrétiser nos objectifs !

En outre, comme nous l'avons fait avec SvelteKit, nous cherchons à inclure une intégration de meilleure qualité aux frameworks existants, afin que Pages puisse devenir le premier choix pour l'hébergement de vos frameworks préférés. Nous travaillons actuellement à intégrer NextJS, NuxtJS, React Server Components, Shopify Hydrogen et bien d'autres technologies de la manière la plus harmonieuse possible à mesure que vous développez vos applications full-stack.

Enfin, nous nous efforçons d'accélérer la période de compilation, afin de vous permettre de vous concentrer sur la mise en œuvre de modifications et sur l'itération rapide, sans attendre !

Premiers pas

Pour bien commencer, n'hésitez pas à vous tourner vers la documentation de Pages et à consulter notre blog de démonstration afin d'en apprendre plus sur la procédure à suivre pour déployer des fonctions serverless sur Pages à l'aide de Cloudflare Workers.

Bien entendu, ce que nous préférons, c'est voir ce que vous avez développé ! Connectez-vous à notre Discord et montrez-nous de quelle manière vous utilisez Pages pour développer vos applications full-stack.

To get started head over to our Pages docs and check out our demo blog to learn more about how to deploy serverless functions to Pages using Cloudflare Workers.
Nous protégeons des réseaux d'entreprise entiers, aidons nos clients à développer efficacement des applications à l'échelle d'Internet, accélérons tous les sites web ou applications Internet, repoussons les attaques DDoS, tenons les pirates informatiques à distance et pouvons vous accompagner dans votre parcours d'adoption de l'architecture Zero Trust.

Accédez à 1.1.1.1 depuis n'importe quel appareil pour commencer à utiliser notre application gratuite, qui rend votre navigation Internet plus rapide et plus sûre.

Pour en apprendre davantage sur notre mission, à savoir contribuer à bâtir un Internet meilleur, cliquez ici. Si vous cherchez de nouvelles perspectives professionnelles, consultez nos postes vacants.
Full Stack WeekCloudflare Pages (FR)Cloudflare WorkersFull StackDéveloppeursDeveloper Platform

Suivre sur X

Nevi Shah|@nevikashah
Glen Maddern|@glenmaddern
Cina Saffary|@1000hz
Cloudflare|@cloudflare

Publications associées

31 octobre 2024 à 13:00

Moving Baselime from AWS to Cloudflare: simpler architecture, improved performance, over 80% lower cloud costs

Post-acquisition, we migrated Baselime from AWS to the Cloudflare Developer Platform and in the process, we improved query times, simplified data ingestion, and now handle far more events, all while cutting costs. Here’s how we built a modern, high-performing observability platform on Cloudflare’s network. ...