We'll take a look at the default code in index.js
in a Workers project. We'll take a second to understand how it works before building the rest of our project.
First will see what our Worker looks like in an actual browser by running wrangler preview
. In a terminal, and we'll check out how Serverless functions in Cloudflare Workers listen for HTTPS requests via the "fetch" event and respond to them by creating and returning a new Response.
Kristian Freeman: [0:00] We created our first project by using wrangler generate without passing in any sort of template or any sort of GitHub repository URL. Now, what we're looking at is index.js, which is the default code for the default Worker's template.
[0:16] If you want to see what this Worker looks like in an actual browser, it's actually straightforward. We'll just open up a new terminal, and we'll run wrangler preview. You can see because of some output here saying your config file is missing the following fields, account ID, so we're following back to an authenticate preview.
[0:35] That's OK for now. Though, we'll come back and configure this wrangler.toml later on, so don't worry about it too much. You can see that there's two important things here. First, your worker responded with, Hello Worker, which is great. That's what we would expect down here in our new response, but we also have this URL that I can copy here.
[0:54] We can go and look at it in browser to see what this serverless function actually returns when we would view it in a browser. I've opened this up in browser, and you can see that I have this testing environment here. I have these three tabs, Preview, Testing, and Documentation. For now, I can see that it's just testing here using example.com. It's like an example URL.
[1:16] You can use this for testing, for instance, like a specific URL, maybe, /about or things like query parameters, so, Hello = world, all kinds of different things you can do here. Importantly, you can see that to make sure that our function actually works, we had this, Hello Worker, text back here in the browser. We know that even by generating a new serverless function, we're already getting some content back here as the response of that function.
[1:47] Before we jump into the rest of how to write a worker, it's worth checking out how the basics here work, because it'll help you understand how to basically write any kind of worker that you would like.
[1:57] First, we'll start with the addEventListener here at the top. A lot like a browser EventListener, this looks for certain kinds of events. In this case, we have the FetchEvent, and it responds to it with a function.
[2:10] In the Workers world right now, we have two kinds of events, fetch, which is a HTTP request, and schedule, which is if you would like to add scheduled workers, you can run on some sort of time basis. For now we'll just cover the FetchEvent.
[2:25] We say addEventListener, look for this incoming FetchEvent. Then we specify a callback function, which is how our worker responds to that incoming FetchEvent. Inside of this function, we have event.respondWith. This is what is telling the FetchEvent, or telling the worker, how we actually want to respond to any incoming request.
[2:47] In this case, we'll call this function, handleRequest, passing in event.request, which represents all of the information about the request itself. Inside of handleRequest, you can see that it's an async function, we're taking request in as the parameter. Inside of that, we need to return a response. An HTTP request comes into the Worker, and out of the Worker comes a response.
[3:14] The response class has a lot of different things you can do with it, but the basics are this. First, you have a body. In this case, it's just a string called, Hello World. Then you have a set of arguments that we usually call Options. Though in the docs, they'll sometimes refer to this as init.
[3:30] The args or init, whatever you want to call it, usually includes headers, it includes status codes, all of the associated things that aren't necessarily related to the body of the response itself, but are still really important for both the users and browsers to understand what this response really is.
[3:48] For now, we just have this headers object, it's really simple. It just has content type, and it's set to text plain. Overall, this response just returns this text, Hello Worker, and header defaults to saying, "This response is coming back is just a plain text response."
[4:06] You'll notice here that, although we're passing in request into this function, we're not actually using it at all. In a future lesson, we'll take a look at what's inside of this request and start to get some important information from it.
[4:19] The basics that you need to know right now are that every worker, if it's responding to a fetchEvent, needs to call event.respondWith. Inside of event.respondWith, you'll pass a function, and that function needs to return a response.
[4:36] If you're familiar with JavaScript and understanding async/await code, you'll notice that this is an asynchronous function. Not only can you return a response, you can also actually return a asynchronous function that resolves into a response.
[4:52] For instance, if I needed to go make a fetch call, or make an HTTP request to something else, say an API or a database or something like that, I can do all of that inside of this function as long as I return a response at the end of this.
[5:09] There are all kinds of different things that you can include inside of a Response. To take a look at what those things might be, you can go into our docs and find the Runtime API section and find the Response.
[5:20] Inside of that, you'll see this type signature of what all responses should look like, including how to set a proper body, and what that body needs to be in terms of the type, whether that's a string, or a form data, or anything else there, as well as things like status, headers, and everything else that you can set inside of the Response.