Over the weekend, at JSConf EU 2019, @ag_dubs took the stage to tell the conference about the serverless platform we've been building at Cloudflare.
Liquid error: internal
Immediately after that talk ended, a massive amount of updates for Cloudflare Workers went live. Seriously - even one of these would be an exciting release, but altogether, the team shipped six new updates to our serverless platform:
- An official, open-source Workers CLI tool, Wrangler
- A new and improved documentation
- Support for deploying multiple Workers scripts to your domain
- Free workers.dev subdomain to deploy your applications
- A free tier for Workers: up to 100k requests per day (!)
- An improved interface for editing and publishing your applications
The result: a super fast platform to deploy your serverless applications, and a rock-solid CLI tool, with the documentation to back it up.
🎁 Updates to @cloudflare Workers today:
🆓 100k requests/day free tier
🤠 A brand-new CLI
📔 Brand new docs site
🥳 Free workers.dev subdomains to deploy your projects
More on this next week, but check out @ritakozlov_'s writeup 👇
blog.cloudflare.com/just-write-cod…14:21 PM - 02 Jun 2019
So! With all that said, how do we get started? One of my primary goals as the developer advocate for Workers is to make it easier for developers to get started with the platform. With the launch of our new CLI tool, this is easier than ever. Let's deploy a simple application using Workers, so we can see what this looks like in practice.
Quick aside: to deploy your application to Workers, you'll need a Cloudflare account. Good news! We have a fancy new sign-up flow to help you do that. Sign up here.
Installing and Generating
Wrangler is our shiny new command-line tool for creating, building, and publishing Cloudflare Workers projects. Installing it is super straightforward:
npm install -g @cloudflare/wrangler
To ensure Wrangler installed successfully, run wrangler --help:
One of my favorite Wrangler features is the generate command. We've built a ton of templates (check out our Template Gallery) that make it super easy to started with a new Workers project quickly. By default, Wrangler uses our JavaScript + Webpack template, so you'll be able to immediately begin working with NPM packages and use new JavaScript features in your project. Let's try the generate command now:
wrangler generate my-first-app
cd my-first-app
Behind the scenes, Wrangler uses Git to make a copy of our template and fills in your configuration details, to make the project your own. Now that you've created a project, let's look inside the code, by opening index.js:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
/**
* Fetch and log a request
* @param {Request} request
*/
async function handleRequest(request) {
return new Response('Hello worker!', { status: 200 })
}
Every Workers application begins by listening for a fetch event. When a client makes an HTTP request to your application, your Workers code can respond to that event using event.respondWith: that response should, fittingly, return an instance of the JavaScript Response class.
Our event handler, handleRequest, is pretty simple. It takes in a request argument (of type Request), and creates a new Response to return to the client. This response returns the text "Hello worker"; by changing the body of your response (the first argument), and setting custom headers and statuses, you can build and return any response to the client that you'd like!
If you've ever worked with Service Workers, this API should be familiar to you. The Workers platform API is modeled heavily after the Service Worker API, so even if you're new to developing on the Workers platform, things like addEventListener and event handling should help you feel a little more comfortable - it's still just JavaScript!
All Workers applications are deployed to "the edge": it's a fancy term for the vast network of Cloudflare servers around the world. What this means in practice is that your application is served very close to your users. This model of building edge appliations is a pretty remarkable shake-up of the typical client/server model: your users don't need to make requests back and forth from a server in Virginia to work with your application - instead, your application will be published to the closest Cloudflare server to all your users, around the world. Building applications on the edge is super exciting, and I'm stoked to be able to continue to explore the implications of that in the future.
Configuring and Publishing
With an application handling requests, and serving responses, we can now take our code and ship it off to the edge! While Wrangler is great, unfortunately, we can't escape having to do a little bit of housekeeping, in the form of configuration: Wrangler needs your Cloudflare account details to be able to deploy your projects successfully. You'll need a few values from your Cloudflare account to deploy code to Cloudflare Workers:
- Global API key
- Email address associated with your Cloudflare account
- Account ID
To find those values, we've written up a brief guide in the docs for you to get the info quickly: "Finding Your Cloudflare API Keys"
With those values at the ready, let's configure Wrangler to deploy to your Cloudflare Workers account. To do this, we'll use Wrangler's config command! Running wrangler config should prompt you interactively for both your email, and API key:
To configure Wrangler to deploy to your Cloudflare Workers account, set up your default credentials via the config subcommand. You should only need to do this once. Running wrangler config should prompt you interactively for your email and API key:
$ wrangler config
Enter email:
foo@bar.com
Enter api key:
123456abcdef
To configure your project, complete the wrangler.toml file at the root of the generated project. This file contains the information Wrangler needs to connect to the Cloudflare Workers API and publish your code. Our main task in this file is to fill in the account_id field, with the value found in your dashboard.
# The name of your Workers application
name = "my-first-app"
# Your Cloudflare account ID
account_id = "$yourAccountId"
# The kind of application you're deploying to Cloudflare (defaults to "webpack")
type = "webpack"
One more configuration step, and it's an important one: it's time to pick your workers.dev subdomain. Each Cloudflare user gets one, so pick wisely! For my projects, I'll be deploying to signalnerve.workers.dev. When you're ready to claim a subdomain (you can skip this if you already have a subdomain), use the subdomain command:
wrangler subdomain signalnerve
Wrangler's updated configuration means that all new applications will be deployed onto that domain: for instance, our project my-first-app would be published at my-first-app.signalnerve.workers.dev.
With a configured subdomain, the only thing left to do is publish our project. Hooray! As you might imagine, we have a command for that, too:
wrangler publish
Wrangler will take your project, build it, and send it up to our network. Almost immediately, you should see the project running live at your domain:
And with that, we've deployed our first Workers application - nice!
Where do we go from here? If you're interested in learning what you can build, our new documentation has some great tutorials to help you build an application or build a serverless function, and as mentioned previously, a growing number of templates in the Template Gallery to use for your next great project.
Did you deploy something using Workers? Please let me know! I'd love to hear about what went well (and what didn't) on Twitter.
Top comments (2)
I am really exited with the latest announcements!
When Cloudflare announced
workers.devI instantly had an awesome idea so I signed up immediately for my own subdomain, also made a blog post about it:Cloudflare announced workers.dev
Glenn Carremans ・ Feb 19 ・ 1 min read
Now with the free tier and that in combination with the new Cloudflare Image Resizing this couldn't get better for my idea 😂
I want to start on it very soon and hope to make it open source shortly after release.
Will probably need to research how caching is done in workers and if there is anything I could do for performance improvements.
Kristian,
The hyperlink of wrangler github is broken.
The link present next to this heading "Installing and Generating"
Thanks