💻 Dev Challenge: Hello Worker Live!

Hey, it's Developer Week here at Cloudflare. So part of Developer Week, Kristian and I have been working through a whole heap of developer challenges and today, hi Kristian, today we're here to talk through the solution to the first one, Hello Worker.

So the developer challenges were built out to give people a great excuse to just experiment with the Cloudflare tooling and we're pretty proud of what we've built here.

So without further ado, I'm going to hand over to Kristian to show us how to do the Hello Worker challenge.

Hey everyone, yeah, let me share my screen.

Can you see that okay, Gretchen? Yeah, that's perfect. Yeah, cool.

Right, so like you mentioned, we have daily challenges Monday through Friday and the first one, which many people probably have already completed, whether that was yesterday or just like from using the platform, was to deploy your first project, specifically using Wrangler.

So I think we're going to kind of take this opportunity to, you know, kind of walk through all of the basics, right, because it's it kind of sets the stage for everything else for the rest of the week.

So I imagine we'll probably do a little bit of sort of installation and like configuration and all of that kind of stuff.

And then ultimately, I think at the end of the 30 minutes here, hopefully we have some sort of deployed project or I don't know, something.

How does that sound? That sounds great. And then everyone will be set up for the rest of the challenges that go throughout the week.

Exactly, yeah. So real quick though, I do want to mention before I forget, so there's a free Egghead course that I did, which is egghead.io.

I'm not going to read that URL.

I'll say it's in our documentation, though. I think if I go to developers.Cloudflare.com slash workers, tutorials, there's this introduction to Cloudflare Workers here.

That's where you can find this. And maybe I'll leave the docs open.

I imagine we'll come back here a couple times. But really, the challenge is sort of I don't know how you would say it.

It's kind of a companion piece to the course, I guess is maybe how you would refer to it.

Like there's kind of videos here on configuration and installing Wrangler and writing your first Soros function, though.

I'll try and do my best to cover all of it in 30 minutes. Let's see.

I just want to jump in for a moment and say two things there. One, I love that they're broken down into miniature videos.

So you can do each piece as you go and then go back to the bit you might have not got right.

Or if you may, you kind of skipped over because you thought you knew that already.

Then you realize you did it wrong and you have to go back.

And also, what I forgot to say earlier is we can answer questions if you've got any as we go.

You just need to email, I'm going to read this, livestudio at Cloudflare.tv.

So any questions, if you send them through to that email, so livestudio at Cloudflare .tv, they'll come through to us and then we can talk to your questions as we go.

Sorry for interrupting there. Oh, no, no worries.

Yeah, that's great. And if you do get questions, feel free to interrupt me and we can kind of walk through them.

So yeah, cool. So in terms of kind of prerequisites or things that you need before we get started, really the only thing that you're going to need is a Cloudflare account.

So Workers has a free plan.

It's very generous. It'll definitely cover anything we'll do here in this challenge.

So as you might imagine, I already have an account. So I'm going to skip that aspect of it.

But just go to Cloudflare.com and create a account. So yeah, we're going to be using Wrangler.

So let me open that up here. It's just on GitHub Cloudflare slash Wrangler.

So this is our open source command line tool for deploying Cloudflare Workers and a number of other things as well, like previewing it and configuring it.

It really is kind of the go-to for anything related to Workers and the ecosystem surrounding it.

So there are a couple different ways to install this.

Can you see that text okay? Maybe I should make it a little bit bigger.

I know from experience that any text size that I think is too big, I should go two or three times past that and that will be the right size.

So by the end of this, it'll be like one letter on the screen at a time.

That's the right font size.

So yeah, with Wrangler, easiest way to install it is this command here, which I'll just copy.

It's npm i, which is install. And then the package name is at Cloudflare slash Wrangler.

And then that dash G flag there is just to install it globally.

So I already have it installed. So I can kind of prove that to you by just running oh, my gosh, wait, do I not have it installed?

That's hilarious. I think I just changed my Node stuff.

Well, perfect reason to run that then. That's hilarious that I said that and don't have it installed.

Something about live coding. Yeah, I know.

Live coding, everything that can go wrong will go wrong. So yeah, it's a fast install here.

This is like three seconds. And now if I run Wrangler version, okay.

There we go. So now I have Wrangler installed. So yeah, let's get started, I guess, making our project.

I don't know if you can see this little Zoom window.

Can you see the one that I have of the two of us? Yes. That I'm moving around on the screen?

Okay. So I'm going to put that in the corner, and I'm going to full screen this for a little bit.

So I'm just in a terminal. Doesn't really matter what terminal.

I just use the VS Code one normally. If I run Wrangler here, you can see there are a bunch of different commands.

I'm running Wrangler 1.15. A lot of these are kind of more complex things like working with KV or routing and secrets.

There's all kinds of stuff here. We're going to get to generate today. That's going to be for making a new workers project.

We'll probably use dev as well, which is for local development.

And then, of course, we will use publish to actually send it.

I didn't know that it said publish your worker to the orange cloud.

That's fun. I feel like that's something we probably wrote in version 1 or 0.9 and then never changed.

That's really funny that it says that. It's so informal.

We were being cheeky. Yeah. So let me just hop into my source folder here, which is where I usually keep my projects.

And so basically what you need to know is that starting a workers project with Wrangler happens via this Wrangler generate command.

And so Wrangler generate is basically a way to use templates for your project.

We have a bunch of them. If I can pull up the docs here. If you come into this get started and then this quick start section here, which I will, again, make a little bit larger, you can see how this command works.

So it's just Wrangler generate and then project name.

I don't know. What should we call the project? Challenge.

Dev challenge or something like that. And then your GitHub repo URL. This is going to be like a template of some kind.

So we have a bunch of them. We have like a JavaScript one, TypeScript.

We have worker sites. We have a router. We have all these different things.

Though it's worth mentioning, if you do not pass a GitHub repo URL, it will just use our default starter template.

So I'm going to actually just do that.

I'm not even going to use a template or not going to pick a custom one, I guess you could say.

So I'm just going to give it a name. So I'll just say dev challenge one.

So that is going to basically create a project. And then it's going to so you can see source dev challenge one.

And that's going to give me some information.

So you can find your zone ID in the right sidebar of a zones overview tab.

That's if we want to do custom domains. We also have the same thing for account ID.

So this is pretty crucial. And this is actually going to be how we're going to deploy our project.

I am going to grab one of these. Let's grab that one, the workers DX one.

And then that'll be the account that we deploy this worker to.

So are these all different accounts you've set up for different things you do with Cloudflare?

Yes. And it is important and worth mentioning that these account IDs are totally okay to share well on a Zoom call or on a stream or whatever.

So they don't do anything unless you have a associated API token. Though I do think that we'll have to show configuring this.

So maybe I'll just skip this for now.

Because I actually I'm going to show Wrangler login here in a little bit.

And I'll end up actually grabbing a different account ID than this one. So for now, let me just open up Dev Challenge.

I'm just going to open this in a new VS Code window.

You can still see that, hopefully? Yeah. Yeah. Okay. And then, you know, now I can actually look at the code here on the side, right?

So not a ton for you to know in terms of things in this project, right?

So like there's a lot of these kind of configuration files and stuff like that.

The crucial ones are your index.js, which is your, you know, your actual code for your worker.

And then you have package.json, which just is a couple things about your JavaScript project.

So like a name here.

You can set up scripts and you can add dependencies and stuff like that, which I think we'll probably get to a little bit later if we want to add web pack and things like that.

We'll see how much time we have. And then the last thing, which is pretty important, is your Wrangler.toml.

So this is a specific configuration file for Wrangler that says, you know, what the project is called, what the account ID for it is, if we're deploying to workers.dev.

And then if we have a custom domain, that's where this information goes.

So basically, kind of rule of thumb here is like your two important files, at least at the start for really basic projects, are Wrangler.toml and index.js.

So I'll just keep those open, actually.

How am I doing so far? Any questions do you have? There's no questions that have come through.

I think the only thing I ever got confused about in the start was whether my account ID needed to be secret or not.

But you've already covered that off.

So let's talk about the login stuff. Because we'll get to the there are some things that are secrets, right?

And those are the things that will I'll show you what those are.

I want to show you themselves what the secret is.

But I'll, you know, I'll show you what things you do need to be a bit more careful about.

But yeah, account ID. You know, normally people will use Git or something like that, right?

And Wrangler .toml will be a part of that. And so like, you can just have your account ID in plain text.

And that's, that's totally fine. So yeah, let me open up a terminal here.

I'm going to plant this down on the bottom. Where do I click to do that?

There we go. Move panel to bottom and I'll just make some more space here.

So yeah, with with a new so let's say you just installed like I already have Wrangler or I thought I had Wrangler installed, but I clearly like use workers a lot, right?

But let's say this is your very first time using Wrangler and your first time using workers.

The first thing you want to do after you generate a new project is you want to like authenticate or log in with Wrangler.

And so we have a command for that.

It's Wrangler login. So I'm going to just press enter here and it's going to say allow Wrangler to open a page in your browser.

I have some weird code terminal stuff set up.

So I don't know. Yeah, I don't think it actually will open a link.

But if you had a normal setup and didn't have like a crazy person set up like me, it probably would work.

But in this case, I'm just going to control click here.

So this is a specific login thing. What this is going to do is set up a new API token for Wrangler that tells, you know, tells our API that is like Cloudflare's workers API.

Like, hey, this instance of Wrangler is okay to publish, publish project, you know, add custom routes and attach to custom domains and stuff like that.

So I'm just going to click authorize here. You can see that it wrote a file here.

So Wrangler config default.toml. I'm not going to open that up because that is like the API key that I shouldn't show on stream.

That one is the secret. But you'll know that this works if you run Wrangler who am I.

It's going to give you a list. You remember that list that we saw at the beginning when I first generated the project.

So this is for my personal account.

I've now moved to my other account that I was logged in with in the dashboard.

So this is the account ID for my personal account. So what did you have to be logged into Cloudflare already in your web browser for that to just go through so quickly?

Yes. Yeah. That's a great question. Yeah. So I you can see if I click up here, I'm already logged in.

This is like my personal workers account, my personal Cloudflare account.

So yeah, it will open up the dashboard, which in the web, and you'll be logged in.

If you install Wrangler and you're not yet logged in, you'll get kind of intercepted into like a login page, right?

And then you can create an account if you don't have one, and then try again.

And once you're authenticated, then it'll send you to all of this.

So that's a good question. Easy. Easy solution.

Yeah. Yeah. The Wrangler login thing is from last summer, I think. We didn't have that before last summer.

I think it was an intern project, a really useful one, which is awesome.

So yeah. So we have our account ID, I'm just going to grab it here, and I'm going to copy it.

And then, as you might guess, we're just going to paste it in right here.

And that's going to say, when I publish this worker, I want to publish it to this account.

So that's my personal Christian at Christian Freeman.com account.

Whether you're on a team or whatever, this account ID can be whatever, it can tie to whatever account you want to deploy to.

If you even want to get more advanced, there's the concept of environments, which let you deploy to different places.

You can even use different accounts there too. There's all kinds of different options and things you can do, depending on your setup.

I would say we have a pretty robust account system, which can be a little overwhelming if you're like me and you're on like a dozen accounts or whatever.

But it also is super flexible.

So that's great. Cool. So I'm just going to put this in here and I'll show you why this matters when we publish our script.

But we're not quite there yet.

I think let's actually go in and look at the code and I'll kind of walk through the basics of a worker.

How does that sound? That sounds great. I also love, I don't know if anyone's watched Mean Girls, but one of the characters and it's called Gretchen.

And that's how people started remembering my name ever in the universe.

And she spends her entire high school career trying to make Fetch a really cool thing.

Trying to make Fetch happen. The meanest mean girl. And it goes, Gretchen, you're just not going to make Fetch happen.

But I get a funny feeling that here today, we will indeed make Fetch happen.

Stop trying to make Fetch happen.

Yeah, that's funny. I never thought about that. Yeah. Yeah. So this is our index.js.

So this is our very basic template. And this shows really like the very bare minimum that you need to deploy a worker that like does something up to our edge.

So I'm just going to take it piece by piece here. So every worker's script is going to have this add event listener.

If you've worked with JavaScript before on the client side, you know that there's this concept of events, which you kind of listen for, you kind of like hook into as a way to sort of think about it.

And when that event happens, you have a function, which is this right here, that will respond to that, right.

So in this case, we're going to, we're going to listen for the Fetch event, which is going to represent a incoming request to our worker.

So if I deploy my worker up, and then you know, Gretchen goes on her phone goes to my worker, that incoming request my worker is, is this Fetch event.

So then the second argument here to add event listener is a callback function.

And that's going to be called when that event fires, or I don't know what the technical term for that is.

I'll just say when the event fires, that seems right ish to me. So this callback function gets this parameter event.

And then there's basically just one thing that we want to do here in the simple case, so there's a lot more on this event that you can dig into in our docs.

But primarily, what we want to do is call event dot respond with, and then we want to pass in a response to that respond with or technically, if you want to get complicated, it can be a response or a promise that resolves to a response if you're doing asynchronous code at all.

So basically, a request comes in, right, a Fetch request from like my phone or from Gretchen's computer or wherever, right?

That request comes in, and we give the client back some sort of response.

And so we set up that response by using this handle request function.

And then we just pass in event dot request, which is a let's say it's a type any here.

That's not true. I probably just don't have my type stuff set up because this isn't a TypeScript project.

But you know, it's a request type, again, in our documentation, and we'll kind of explore it here as we walk through this.

So yeah, the gist here, I think really important. I really like stress it over and over again, because I think it's a really important mental model for people to understand.

Fetch event comes in, you return some sort of response to that incoming request.

How did I do? Does that make sense? That made sense to me.

But if there's any questions, again, flick them through to that email address, which is live studio at Cloudflare.tv.

Cool. Yeah, cool. So looking at this handle request function.

So this is an asynchronous function. So I mentioned that it can either be a response here, right?

Or it can be a promise, which resolves into a response if you're going to do asynchronous code.

And in this case, it actually is async, right?

So we mark it as async. And then it's a function called handle request.

It just has one argument here, which is a request. And then inside of that, we just return a new response.

Let me pull up real quick, because I think it is pretty important.

If I go to our docs here, and I'm just going to go to runtime APIs, and then I'm going to go to response.

So we have basically an implementation of the standard response class.

You could find this on like MDN or, you know, any sort of JavaScript documentation site.

So we have an implementation of the response class that is, I think, pretty conformant.

It's pretty close to spec.

I'm not sure what the exact differences are. But functionally, you can think of it as basically identical to the response spec as defined by like the JavaScript, as I say, like a JavaScript consortium.

But I don't know if that's what it's called.

It's something very serious sounding like that, though.

But the basics here is it takes two arguments. So the first is a body.

This is the body of your response. That could be like a string. It could be HTML.

It could be like scary binary data. Like it could really be all sorts of different things.

And then the second thing here is what we call init, though you can kind of think of it more as like options.

And this is additional configuration to accompany the response body.

So that's things like a status code. So that generally defaults to 200, though if people are familiar with HTTP status codes, there are a bunch of them.

I guess the other probably known one would be like 404, which would be a not found status code.

So there's a bunch of these different status codes.

You can set a status text as well. And then there's also headers, which we will use a little bit later on here.

And headers, as you can see it, we actually set one for you here.

It's just an object. And it's a key value pair. In this case, we use the key content type and then we set it to text plain.

Again, content type is actually a whole other like spec where there are a bunch of these defined.

So there's text plain, text HTML, there's image slash JPEG. These are all kind of strictly defined specs where you can implement things and say, like, hey, this response is plain text or this response is HTML or et cetera, et cetera.

So given that strictly defined, would I be right in assuming if you don't define the right one, just nothing happens?

That it would be nice if that were the case. But unfortunately, it's probably one of those situations where it depends on the browser and it depends on how the browser handles it.

Oh, my dog is upset at us. So, you know, if I try and return something as an image that's not an image, right?

It's a great question what the browser is going to do.

**SARAH HANSEN** No one knows. **JASON LENGSTORF** It depends.

Yeah. And that's an unfortunate thing of building for the web.

There's probably people here at Cloudflare who know better about that than I do.

But, you know, that's definitely a thing to be aware of. In my Egghead course, I have a section where basically, you know, it covers what happens when you don't set the right content type, which maybe we can get into in a sec.

I know we're actually we don't have that much time left. **SARAH HANSEN** No, we don't.

We've got about eight minutes. Do you think we can get a worker? **JASON LENGSTORF** Yeah.

So I'll show you the last little part I'm talking about when it comes to content type.

But, yeah, let's actually deploy something. I spent a lot of time covering how it works, which I guess is fine, right?

That's kind of the basics.

**SARAH HANSEN** If you know the how, the doing is easy. **JASON LENGSTORF** Yeah.

So, basically, I would say there's two things you need to know when it comes to actually publishing your worker.

So the first is going to be Wrangler publish, okay?

And that's like the very basic, like, let's just send what did I say earlier that it said?

It was like, let's send our worker to orange cloud or whatever the description text was there, right?

So if I run this command, what's going to happen is it's going to look at my account ID, which is what I put, I'll show you again, what I put here in Wrangler toml, right?

It's also going to look at this bottom section here.

So workers dev is set to true by default. And then route and zone ID are empty.

So workers underscore dev here is a configuration option that lets you deploy to workers.dev, which is a kind of like a preview thing that we have set up.

You can see mine is signalnerv.workers.dev. And so the kind of URL that this gets deployed to is literally just the project name.

So dev challenge one, right?

That's what we called it when we generated the project. And then your workers.dev subdomain.

If you haven't published a workers project yet, and you try and run Wrangler publish, it'll actually tell you like, hey, you don't have a subdomain yet, you should grab one.

And it'll give you instructions on how to do that.

I don't think I can recreate that here because I'm using an existing thing.

But basically, you get like a unique URL that only you can deploy to.

And yeah, so you'll see, you know, people do like usernames a company will grab their company name.workers.dev or whatever.

So it's a unique space for just your projects to be deployed to.

So if I open this URL up, you should be able to see hello, worker.

I'll blow this. Boom. 500% text. So it's really that easy, right?

Like if I think this is probably I didn't actually time it, but it's like two or three seconds basically, right?

And so you have this really quick iteration loop. You're now deploying stuff to this workers .dev instance.

I could also give it a custom domain.

So if I came back here and did the route in the zone ID, I could deploy to Christian Freeman.com or I could deploy to, you know, I shouldn't deploy things to Cloudflare.com.

That would be dangerous. But hypothetically, right? I could deploy to any of these places.

So that's publishing. And anytime I change something, so if I say like, hello, worker, or I say like, hello, Cloudflare TV, and then I do Wrangler publish, you can see it's just what is this?

Four, five seconds.

Let's say like five seconds-ish. That'll, you know, build the project, though in our case, there's actually no build step because there's no dependencies or anything like that.

And then if I refresh here, you can see that it shows up instantly.

So you have this really quick iteration loop, which is really handy when you're kind of experimenting with stuff.

Though, what do we got? We got five minutes left.

I'll show one or two more things. One of which I think is really useful, which is called Wrangler dev.

So let's say that I made my project. I'm happy with it.

It is like out in production, right? And now there's a time where like, I'm I have to be really careful about how I deploy my project, because if I mess something up, there's people that rely on the deployment or whatever, right?

Like very anytime a project is like serious, yeah, production becomes an important thing.

So what we have instead is Wrangler dev as a solution to like, okay, now my project is serious business.

I need to be a little bit more careful about how I develop with it and stuff like that.

What Wrangler dev does is it deploys your worker to a preview instance separate from, you know, separate from this workers.dev deployment here.

And it also makes it available locally. So if I click this link, you can see that I now, of course, the text size, I'll blow back up here again.

It's now accessible from localhost colon 8787. So I can develop on it locally.

And if I change stuff, let's say like, hi, Cloudflare TV, you can see that in my console here, it detects changes.

And then if I refresh, you can see it says, hi, Cloudflare TV, right, on my localhost.

But if I refresh here on workers.dev, it hasn't updated it.

So, you know, we have local development where you can say, well, it's like kind of local development, it still actually deploys to a preview instance, but it doesn't change anything about your actual published worker, right?

You also get things like console log, which is really nice. So I can say hello from the console.

So if you need to test things, you need to kind of understand what your code is actually doing.

Come back here to localhost and refresh, you can now see hello from the console here in, well, in my console.

So yeah, that, how much time we have?

We have three minutes? We've got two minutes. Two minutes.

Any questions or anything you think we should mention to people in regards to No questions come through.

But I know when I was first using workers, I got a little bit caught out with my config file when I tried to install some packages.

Did you want to talk me through what I should have done there? Oh, sure. Yeah.

So the short version is basically we have this type here, which we default to JavaScript for you.

This is a like no build JavaScript project, meaning that this index.js has no dependencies.

That allows it to be a really fast deployment process because there's no kinds of builds or anything like that.

If you're using NPM packages, or you have other files in here, let's say I set up like, I don't know, cool file.js or something like that, and I need to import it, you need to come in here and you need to change this to webpack.

So what that is going to do is it's going to run this through webpack, which is a JavaScript like build tool.

So it'll grab any NPM packages, it'll kind of package it all together into this neat little bundle.

And that will allow you to use external packages or other files. And you can just import them like you'd expect.

So yeah, people do get kind of caught up on that.

The good news is the webpack type doesn't add that much overhead in terms of build time and stuff like that.

But the JavaScript one, by default, there's no builds or anything like that.

It's just literally like a single file.

So it's very, very fast. I'll also plug I've got a question come in from the audience, just for 20 seconds.

It says, are you planning to support ESM or some other module loading mechanism in workers?

Great question. We and I know we don't have that much time left.

We have a custom build thing that we're working on in Wrangler right now.

You should join us in the Discord and beta test that. It'll allow you to use any sort of custom build stuff.

How much time do we have left? We've got 20 seconds.

So I think what we should say now is, oh, my goodness, thank you for watching at whatever time zone you're in.

It's been great to see you. But we would love you all to come over to our Discord channel because the answers to those questions and everything else often get covered there.

And if we haven't covered them, they will be.

So join our Discord server. If you Google Cloudflare Community Discord, you'll get there.

Thank you so much. We've enjoyed talking about workers.

Thank you, everyone.