Il y a exactement un an aujourd'hui, Cloudflare m'a donné une mission : Faites en sorte que les gens puissent exécuter du code dans la périphérie de Cloudflare. À l'époque, nous ne savions pas encore ce que cela impliquerait. Cela se ferait-il au moyen de conteneurs ? D’un nouveau langage Turing incomplet spécifique au domaine ? Du Lua ? De « fonctions » ? Nombreuses étaient les possibilités.
En fin de compte, nous nous sommes mis d'accord sur ce qui semble aujourd'hui être un choix évident : JavaScript, en utilisant l'API Service Workers standard, exécuté dans un nouvel environnement construit sur le moteur V8. Il y a cinq mois,nous vous avons donné un aperçu de nos réalisations et nous avons lancé la version bêta.
Aujourd'hui, avec des milliers de scripts déployés et des milliards de requêtes traitées, Cloudflare Workers est prêt pour son lancement sur le marché.
« En abandonnant VCL au profit de Cloudflare Workers, nous pourrons mettre en place un routage créatif qui nous permettra de fournir JavaScript aux millions d'utilisateurs de npm encore plus vite qu'actuellement. Nous développerons notre prochaine génération de services sur la plate-forme Cloudflare et nous pourrons le faire en JavaScript ! »
— CJ Silverio, directeur technique, npm, Inc.
Qu’est-ce que le cloud, en fait ?
Depuis toujours, le code des applications Web est réparti entre les serveurs et les navigateurs. Entre eux se trouve un réseau vaste, essentiellement non intelligent, qui ne fait que convoyer les données d'un point à un autre.
Selon nous, cette conception du « cloud » n’est pas à la hauteur de ce qu’il devrait être.
Pour nous, le véritable idéal de l'informatique en cloud est que le code soit intégré au réseau lui-même. Votre code ne circule pas dans « us-west-4 » ou en « Asie centrale méridionale », il circule partout.
Plus concrètement, il devrait circuler là où on en a le plus besoin. En répondant à un utilisateur en Nouvelle-Zélande, votre code devrait être exécuté en Nouvelle-Zélande. Lorsque vous traitez des données dans votre base de données, votre code doit être exécuté sur les machines qui les stockent. Lorsque vous interagissez avec une API tierce, votre code doit être exécuté partout où cette API est hébergée. Quand les explorateurs humains atteindront Mars, ils n'auront pas envie de patienter une demi-heure pour que votre application réponde : votre code devra être exécuté sur Mars.
Cloudflare Workers constitue notre premier pas vers la concrétisation de ce concept. Lorsque vous mettez en place un worker, il est déployé en moins de 30 secondes sur l'ensemble du réseau de Cloudflare, qui compte plus de cent sites dans le monde entier. Chaque requête envoyée à votre domaine sera traitée par votre worker dans un emplacement Cloudflare proche de l'utilisateur final, sans que vous ayez besoin de vous préoccuper des emplacements individuels. Plus nous mettons en ligne de points de connexion, plus votre code « circule partout ».
Bon d’accord... sauf sur Mars. Pour le moment. Elon, si tu nous lis...
Qu’est-ce qu’un worker ?
Cloudflare Workers tire son nom de Web Workers, et plus spécifiquement Service Workers, l'API standard du W3C pour les scripts qui s'exécutent en arrière-plan dans un navigateur Web et interceptent les requêtes HTTP. Les Workers de Cloudflare sont écrits avec la même API standard, mais s'exécutent sur les serveurs de Cloudflare et non dans un navigateur.
Voici les outils avec lesquels vous pourrez travailler :
Exécuter n'importe quel code JavaScript en utilisant les dernières fonctionnalités en langage standard
Intercepter et modifier les URL, le statut, les en-têtes et le contenu des requêtes et réponses HTTP
Répondre directement aux demandes avec votre worker, ou les envoyer ailleurs
Envoyer des requêtes HTTP à des serveurs tiers
Envoyer plusieurs requêtes, en série ou en parallèle, et utiliser les réponses pour composer une réponse finale à la requête d’origine
Envoyer des requêtes asynchrones après l'envoi de la réponse au client (à des fins d'enregistrement ou d'analyse, par exemple)
Contrôler d'autres fonctionnalités de Cloudflare, comme la gestion de la mise en cache
Les possibilités d'utilisation des workers sont infinies, et nous avons hâte de voir ce que nos clients nous réservent. Voici quelques idées que nous avons observées dans la version bêta :
Acheminer différents types de requêtes vers différents serveurs d'origine
Étendre les modèles HTML en périphérie, pour réduire les coûts de bande passante à l'origine
Mettre en place un contrôle de l'accès au contenu mis en cache
Rediriger une fraction des utilisateurs vers un serveur de transit
Effectuer des tests A/B entre deux back-ends totalement différents
Créer des applications « serverless » qui dépendent exclusivement d'API Web
Créer des filtres de sécurité personnalisés pour bloquer le trafic indésirable spécifique à votre application
Réécrire les requêtes pour améliorer le taux de succès du cache
Intégrer une logique de répartition de charge et de basculement personnalisée
Appliquer des correctifs rapides à votre application sans devoir mettre à jour vos serveurs de production
Recueillir des données d'analyse sans exécuter de code dans le navigateur de l'utilisateur
Et bien plus encore.
Voici un exemple :
C’est vraiment rapide
// A Worker which:
// 1. Redirects visitors to the home page ("/") to a
// country-specific page (e.g. "/US/").
// 2. Blocks hotlinks.
// 3. Serves images directly from Google Cloud Storage.
addEventListener('fetch', event => {
event.respondWith(handle(event.request))
})
async function handle(request) {
let url = new URL(request.url)
if (url.pathname == "/") {
// This is a request for the home page ("/").
// Redirect to country-specific path.
// E.g. users in the US will be sent to "/US/".
let country = request.headers.get("CF-IpCountry")
url.pathname = "/" + country + "/"
return Response.redirect(url, 302)
} else if (url.pathname.startsWith("/images/")) {
// This is a request for an image (under "/images").
// First, block third-party referrers to discourage
// hotlinking.
let referer = request.headers.get("Referer")
if (referer &&
new URL(referer).hostname != url.hostname) {
return new Response(
"Hotlinking not allowed.",
{ status: 403 })
}
// Hotlink check passed. Serve the image directly
// from Google Cloud Storage, to save serving
// costs. The image will be cached at Cloudflare's
// edge according to its Cache-Control header.
url.hostname = "example-bucket.storage.googleapis.com"
return fetch(url, request)
} else {
// Regular request. Forward to origin server.
return fetch(request)
}
}
Parfois, on nous demande si le JavaScript est « lent ». Rien n'est plus faux.
Workers utilise le moteur JavaScript V8 conçu par Google pour Chrome. V8 n'est pas seulement l'un des moteurs JavaScript les plus rapides, mais aussi l'un des plus rapides de tous les langages de programmation dynamique. L'immense quantité de travail consacrée à l'optimisation de V8 l'a rendu plus performant que n'importe quel langage de programmation de serveurs, à l'exception peut- être de C/C++, Rust et Go. (D'ailleurs, nous les prendrons en charge prochainement, via WebAssembly.)
Conclusion : Un script Worker standard s'exécute en moins d'une milliseconde. La plupart des utilisateurs sont incapables de mesurer la différence de latence lorsqu'ils activent Workers, sauf, bien sûr, lorsque leur worker réduit réellement la latence en répondant directement depuis la périphérie.
Par ailleurs, les workers se déploient également vite. Les workers se déploient dans le monde entier en moins de 30 secondes à partir du moment où vous sauvegardez et activez le script.
Prix
Workers est un complément payant de Cloudflare. Nous voulions simplifier autant que possible la tarification, alors voilà ce que nous vous proposons :
Premiers pas
Connectez-vous à votre compte Cloudflare et rendez-vous dans la rubrique « Workers » pour configurer Workers.
Essayez les workers dans le bac à sable, vous n'avez pas besoin d'un compte pour cela.
Lisez les instructions pour savoir comment sont écrits les workers.
Consultez l’article de blog d’origine si vous désirez plus de détails techniques.
« Cloudflare Workers nous fait gagner beaucoup de temps. Gérer le trafic des bots sans Workers consommerait de précieuses ressources en termes de développement et de serveurs, qui seraient mieux utilisées ailleurs. »
— John Thompson, administrateur système en chef chez MaxMind
Mots-clés : Actualités produits, Workers, JavaScript, Performances, Compression, Développeurs, Serverless