Summer Developer Challenge: Everything You Need To Know

Hi everyone. Thanks so much for joining us today on Cloudflare TV. We want to talk all about our summer developer challenges, what you need to know, what are some example projects that you can do and we'll have the stream open.

So feel free to put in your questions.

We're happy to answer them live here today. My name is Jen Vaccaro.

I'm the product marketing manager for our developer platform. So that includes Cloudflare Workers, Cloudflare Pages, Workers KV, and Durable Objects.

So we're really excited to talk through everything you can build with those products and all the swag that you can win when you submit.

And I'm here joined with Luke.

Do you want to introduce yourself? Hi everyone. My name is Luke Edwards. I'm a developer advocate on the Cloudflare Workers team.

Today I will just be walking through how I built the Cloudflare Developer Summer Challenge landing page and the entire supporting workflows that went into it.

Great. So before we get started kind of deep diving on Luke's project, which definitely counts as a submission for the developer challenge and is very meta because he built all of our backend and front end for the challenge using Workers and KV.

So before we get started on that, I want to give just a quick overview of the challenge, just for those of you who don't know exactly what it is yet.

So basically what we're doing, we have over 300 swag boxes.

This includes a lot of prizes of our most popular swag, including like t-shirts and a cap, Cloudflare mugs, keyboard caps, stickers, and more.

So we wanted to put everything that we used to give out at conferences and people in our community were talking a lot about how much they miss the conferences we would host and missed all of that swag.

So we wanted to use it as a chance to really reward our community for everything that they're building out there.

So the idea of the challenge is we'll be reviewing submissions really based on the projects you've built.

You need to have one Cloudflare or you need to have at least two of the Cloudflare products that you're using in your submission.

So this could be Cloudflare workers plus pages or workers plus KV or workers plus durable objects, kind of whatever mix and match that you want.

We just ask that you have two in your project and that you submit to us via the submit form.

You can look at our webpage. The link should be below in the description here.

It's challenge.developers.Cloudflare .com. And you can go ahead and sign up there and then submit your project.

What we ask is that you submit like your repo just so we can see as you and what you built and then an example, the link to your project itself so we can view that.

And we'll be basing submissions on just really seeing that you've built something creative and innovative.

We have tons of swag boxes left.

So please definitely submit to the challenge and we'll be we'll be reviewing it.

It'll be open between now and November 1st. So be sure you to get your projects in.

We still have a month to definitely get in before then. And you can reach out to me and Luke on Discord if you have additional questions as you're building.

And one of the pieces of the challenge we want to highlight is we have a Discord community.

So we want to get as many folks on there asking questions, interacting.

So if there's anything where you're getting stuck on a project or you need more inspiration and you want to talk with our other participants or our community champs, definitely check out our Discord, the Cloudflare Workers.

And we have support and things like that and a whole channel for our developer challenges.

So you can feel free to chat with other people who are going in building as well.

So that's kind of a high level of kind of what we're expecting with the challenge.

And there's a lot you can bring to build. Luke is just kind of has one example.

Luke, maybe before we get into yours, we can give a little bit of an overview of each of the different products like workers, KV, durable objects, pages and kind of what they are.

Do you want to give a little overview there? Sure. So workers, of course, is probably our most.

Common products, right, or our most well -known products.

And so workers itself is a is a global edge compute system. So you can run your custom application code globally on all data centers that Cloudflare owns.

And it's a very seamless deploy system and it updates very quickly so you can run any custom code anywhere in the world.

With very, very like near zero latency.

Workers, KV is our global replicated key value data store emphasis on global.

So it does replicate. It is an eventually consistent data store. So it is a nice.

Sibling product to go along with workers because both your data and your compute logic are on every data center globally that Cloudflare possesses.

So, again, get your data closest to where users are.

Do the work closest to where your users are.

It's a win win. Beyond that, we have pages, which is built on top of workers.

But pages is a is a done for you solution for static site hosting. So before pages, there was a worker site pattern, and it very much still exists and it can be done.

In fact, that's what I've done for this example. But pages is a way for you to build your site as if there were any other front end application, attach it to pages, attach a repo to pages, and it deploys automatically.

And as with the rest of the theme here, it globally distributes and you have very fast, very low latency, static site hosting everywhere.

And fourth product is durable objects, durable objects.

Are I think of them like workers, but instead of being global and distributed and stateless, global objects are stateful and they are named workers.

They are named instances. So what that means is you can have.

Your let's say thousands of worker instances all. Connecting to the same exact durable object or, you know, a collection of the same exact durable objects.

So you can use that to synchronize state. People are using it to build chat rooms so that the durable objects can host, you know, all of the WebSocket connections and then distribute messages across them because they're all connected to that same focal point.

And those are the four products you can really most everything can boil down to a combination of those four.

And of course, for the challenge, you only needed to use two.

But you can also incorporate external products as well.

Your database. You know of choice, but the requirement for us, for this application, is you just have to use two.

Great, yeah, and what's pretty interesting about all of these ones that you just named is the platform.

A lot of our users have traditionally thought of us as like workers and like the serverless compute piece.

And what we're really trying to to show and highlight in the challenge is like we have a bunch of building blocks across compute storage and now like with pages to build out your front end as well.

Entirely really on the Cloudflare network.

And that's something we want our users to start getting comfortable with and being able to mix and match across and not feel limited just to, you know, compute.

And we have a lot to to build like building blocks as they as they develop their projects.

So that's definitely something we want to highlight. So thanks, Luke, for giving us a rundown.

I do quickly just want to walk through some of the steps.

I'm going to just share my screen and just show a few of the steps on getting started here.

Let me get this up. So really what we what we have is if you need kind of more information on the details, if there's anything we didn't cover today, we have our challenge .developers.Cloudflare.com, which is where you can go to get all the information.

You can go through your sign up flow. And if you need to learn more, we have a whole bunch of questions on kind of how to get started and to to sign up here.

So if there's anything more you need to know, we may have already covered it there.

And then you just pretty easy. You submit, give us a your repo and everything there, and then we'll be sending back responses by probably maybe within a month or so afterwards.

If you haven't noticed, we have a little Easter egg here just giving you some examples of what the swag is.

And you'll be receiving this whole box.

And we encourage you to kind of share your opening of the box or kind of share what your swag prizes are that you you're using.

But this gives you a little glimpse of what you will be winning here and kind of where to go to to sign up.

And also, just for those who are new, haven't maybe you haven't tried out workers or KV before.

We do have a whole getting started guide with workers.

So if you go into our workers docs, you can quickly get up, get some quick starts.

We have a lot of examples and different tutorials. A lot of these tutorials are mixing and matching with like workers, KV and some of our other products or pages, for example.

So these can be a really good base if you do the tutorial and want to submit something very similar to that.

So we want to make sure, you know, like we have these resources for you to get started on.

There's also documentation on durable objects and KV in particular.

In here, if you want to learn more and then we have the same for for pages.

So you can also go through the quick start guide for pages and connect to any framework, really react, Hugo Gatsby, what have you.

And we have all of those templates on the landing page.

So if you're not familiar with all the different projects we have, we have places for you to get started and up and running really quickly here in our docs.

All right.

So that's that's that on kind of the high level overview. Then I want to hand it over to Luke, maybe Luke, before we walk through your example project, I'll just give a couple maybe sneak peeks on some of the projects we're already seeing and would recommend, you know, would maybe give some inspo.

So some of the project we've been seeing with particularly workers and durable objects combined is building multiplayer video games.

That might be one of the more advanced type of examples.

So don't feel like you need to do something as maybe detailed as that. But we are seeing some really cool multiplayer games coming out of workers and durable objects.

Same with like building chat rooms or any sort of like real time collaborative application.

We've been seeing a lot of that. And so that could be some ideas there.

We've also been seeing users building out some things with e-commerce.

So one example we've seen is like you could have your let's say, you know, ordering site on cloud hosted on cloud for pages.

And you could use workers for maybe a B testing of the page or inserting some logic for localization.

So maybe you have like your landing page and you want to localize, you know, have your users see it in dollars in the US or euros in Europe.

So that's kind of one example we're seeing on the e-commerce side.

And maybe the last one I'll give is, you know, we're seeing a lot of users building out APIs and serverless APIs on workers and really enjoying that real time experience there.

So those are some examples. Maybe give you some some inspiration.

Our blog details these in further detail. And now I'll hand it over to Luke, who's given probably our very first ever submission because of the nature of what he did.

So, Luke, I'll hand it off to you. Sure. So while my screen's coming up, just again, a little.

Jen, can you see? Yeah. Great. OK, and hopefully you interject with questions, keep me on track and give me a time estimate at the end.

OK, but so the the application itself, as mentioned, is completely workers and workers.

So I am not all that fancy, so I am not able to do multiplayer games.

But those sound like awesome options. But again, you don't have to do something that crazy in order to submit.

So I have a workers and workers site project, which really boils down to a collection of static pages and a couple of form handlers.

Right. We have a submission form. We have some different pages here. So there's the landing page.

There's a rules page. And then there are other pages along the way, which we'll find out, which we'll see.

From. I have it locally now. So from here, architecturally speaking, I could have made this three projects.

Right.

And maybe I'll speak a little bit more about it at the end. But this could have been workers, workers, KB and pages, right, where pages host all the static assets.

So if I wanted to reach for a third, I totally could have. But I have a longer history with worker sites.

And that's how I came about this. Totally fine.

So I have the site running now on local host. This is the HTML portion. So, again, worker sites is the way it came to be.

It was two to project. There was a front end project and then a back end project, which means I have to build systems for this thing.

I could merge it into a single build system, but time constraints and how products develop.

I didn't spend time doing that. So what we have here is the static site itself on local host 8080.

And this is how I actually built out the site.

I have running in the background an HTML dev command.

And hopefully you can still see this. Jen. Yep, yep. OK, great. So I have everything inside this source directory, and that's my HTML assets.

So there are a couple of things here.

It's really just an HTML site. I don't want to spend too much time on it.

It's a big HTML site, especially the main page. But. I'm trying to think how to actually start this.

So there are there are form methods here, and they are forms that are hooked up to the workers back end.

The really the only thing I want to highlight about the HTML aspect itself was I kind of pose an additional challenge to myself that I spoke a little too much about in my blog article.

But I wanted everything to be wrapped up into a single HTML document, which meant no external assets, which meant no external style sheet or JavaScript file.

No actual requirement to do that. It was just something that I wanted to do along the way.

So I started my HTML build system has this inject directive.

And that is squishing everything into during the build process into a final single HTML document per page so that on the workers side, I have a much easier time actually like sending down those pages.

Again, pure laziness driven. Something like pages definitely would have just taken care of this out of the box.

So would have a the Cloud Player KV asset handler.

But again, I wasn't uploading my assets to KV.

I wasn't doing anything that you should be doing. I kind of just winged it and it worked out.

And I've been doing this for a while. So it's true, as I say, not as I do.

OK, so before we actually get further into that, let's look at an actual form.

Right. So here's the main page source index. It has its own assets. All of that stuff is just static website oriented.

And where did you go form? There you are.

So the main submission form from this page is a form with a first name, a last name, an email and a submit.

Post to slash signed up. Right. So this is native HTML form stuff.

It's going to serialize itself and send it up, which means that this actually works without JavaScript enabled.

But I do have JavaScript actually enabled and it is doing some error management and stuff that we will see later on.

But the post and the destination remain the same, even with the JavaScript. So on the worker's side.

That means I have to handle it. So post post and submit. Went to the wrong one.

Post and sign up. It has to deal with that, which should probably be a good segue into how the actual workers set up.

I'm sorry. A little frazzled.

So everything that belongs to the worker is inside the worker directory. I have a code model, an email model, a sign up model and a bunch of utilities.

But I offer this framework called Worktop.

That's what I've been using for a couple of years now.

Includes a router, a bunch of other utilities we'll see along the way.

But mostly, you know, the router. There's also any router and a bunch of others in the community.

They allow you to organize routes and a. And a, you know, expected layout, something that feels familiar.

So that's what this API dot get stuff is.

API is the base router, and I am now assigning routes to it. So we saw the landing page.

It's a get to the route path. Does something special there. This is a custom utility for this project that will actually render that HTML page.

We'll get to that in a second and has all the other methods and routes just to find in line.

So it does become a big file any bigger than this. I would have actually refactored it so that I had files and files composing in a more sane layout.

But again, it's just topical fixes at that point.

So we have our form. It's a post to sign up.

And this is where some of the other worktop utilities are coming into place.

Worktop gives the original request. That comes in. There are some. Built in utilities on top of it.

One of them is this dot body. So this is not the this is not a core method.

This dot body. What this is doing is it's automatically detecting the content type that was submitted and returning it.

So if it was form data, which happens to be in this case, what it's basically doing is calling request form data.

Right. And that doesn't exist on this actual request object. Hence the error.

That's what it would be calling underneath. If it were JSON, it'd be calling request JSON that were like image content or something.

It could call rec dot array buffer.

So on from there, we have input. Input is type coerced into this entry format or it's missing.

And then there's a bunch of validation in place.

And really, I just want to spend some time on this like main post handler, because every single form submission looks like this.

Take somebody happen to call input, do some validation.

This is all in line custom validation. You know, use whatever libraries you prefer for this.

It was just much easier to do it in line. If there are errors, there's a four twenty two status code that goes back down, which stands for unprocessable entity.

So whatever, it's just something that the client side is going to expect and expect how to work with it.

And actually, let's look at some of that now. So I have this is the real page I've already signed up.

Right. And so I have Luke Edwards, Edwards at Cloudflare.

So this is ready to go. And step one, actually. Step one, there's a client side validation.

I mentioned there is JavaScript that is hooked up to this form.

And so the client side validation is doing the same service side validation that we just saw.

It's making sure that email looks like an email, that first name and last names are not empty and sends it down.

The second phase of validation is. Actually looking at the data and seeing if the state is correct.

So in a first sign up, we want to go in and see, like, have you already signed up?

So this is where this custom sign ups model comes in.

And there's a find method on it. And so now we're inside the sign up file.

This is what our entry submissions look like. And this fine is taking an email and then calling utils dot read.

So utils, again, is my project specific utilities.

And in this particular case, it eventually boils down into a namespace dot read.

So. This is my worktop wrapper, but it's a very two line wrapper that is literally just calling namespace dot get and doing some serialization to the output data.

So for all intents and purposes, this is a native method.

It's just a little bit of abstraction glue on top of it. But the way this file is set up is all namespace utilities are coming from this file, as well as some additional ones, because there really aren't that many.

But this is where all reads, all writes, all removes and all lists come from.

They eventually boil down into a worktop call.

The worktop is always directly doing something with the namespace binding.

So. Before we get there, there's this two key, and that's just to normalize what I'm just going to give you a quick time check.

We have about five and a half more minutes. OK, great.

Thanks. So we take that email, we normalize a key so that every entry submission has the same format, and that goes into.

Listing data later on, because we will always want to list and you should always list namespace keys by a common prefix just so you can get to what you want much faster.

So a time check in place.

We check to see if this email is unique or if it's already been submitted. If it is, we send it down.

And that's this first error I want to show. Right. So error 400, a little message down here.

You have already signed up and that's coming directly from the worker.

Not sure if you can see because of the sign size, but I'll do it one more time.

So error 400, you already signed up, stays there for about 10 seconds on a valid submission test, one, two, three.

What happens is we do the same check, the same initial validations.

We eventually save the sign up, which again boils down to a KB namespace method.

We also generate a code which will get emailed to the user.

But code generation is a unique, is a unique value that eventually gets written down to the code.

So, again, very base, base methods that are easily composable.

And at the very end, we take that code, ensure everything went through and then we use Spark Post to actually send an email.

And this is all open source and you can look at it a little more closely.

But it's just formatting a REST API call for Spark Post using a pre, using a template, an email template and injecting the values from the entry object directly.

So that's where your name and your code and stuff comes from.

If everything is successful, which hopefully it is, we render the confirmation page with your email that shows the like, hey, you know, thanks for signing up.

Please check your inbox for the sign up form.

So I won't show my email, but I'll show what the rest of it looks like.

You know, this is now the confirmation page where it is directly sent down as a response.

The client side JavaScript that is there is taking down this this confirmation HTML and replacing the document body, actually the entire document with this full response.

So because of the way that works, again, my own self-imposed challenge was like, I want to make sure that this entire thing works if JavaScript is disabled.

And because of how this is done, this would also work with JavaScript disabled.

So a little little fun thing, which I always like to do.

Don't particularly want to show my inbox at this point, but the email submission link would be here.

Spark Post is very quick. And from there, I will have a unique authentication code that I can then follow at any point in time to submit my project.

And each of these projects have the same have the same workflow where the submission page has its own form.

You know, forms always post to their own dedicated endpoint.

And every endpoint is doing the same bits of collect the data, validate the data, make sure that everything lines up the way it's supposed to and then send down a successful response.

The last little bit here that some of you may have noticed is that I have these these template tags around.

And that's where this utils.render comes from.

So for what it's doing. So every utils .render call took a response.

The template content itself, the full HTML page and then the values to inject.

And so it's literally just going through like, hey, I see curly, curly count.

So I'm going to replace curly, curly count with the count value or the first name value, excuse me, or the first name value and send it on its way.

And that's always a forced content type with a 200 status code saying like, you know, this is the final format.

In the last minute or so here, there is an admin panel that went along with this.

This is how we are, how we justify calling this an application.

I mean, obviously, it already is an application, but there is a whole back end that allows us to see submissions.

And this is protected with cloud for access so that only our team can see this.

And it's a real time. Obviously, it's been hidden.

The text has been hidden, but it's a real time view to see what.

Like who submitted, what's going on, we can award winners and whatnot from here.

And every time we do that, that is updating our boxes count, which is in real time updating the we've noticed a count variable here.

So the count page, if I refresh this.

This count is a real time update. So the entire application comes full circle where we can track submissions.

We have about 10 seconds left.

OK, well, that's it. The repo is open source. Hit us up if you have any questions.

Great. Thanks, Luke. Thanks, everyone. Bye.