Static first websites with Cloudflare Workers

Rate this content

Static websites give you all sorts of great benefits. You don’t have to worry about security or scalability. They are simple to cache, cheap to host and a breeze to maintain! But sometimes I miss all the fun things you can do with just a little bit of state! Combining the Cloudflare Pages platform with Durable Objects and the HTMLRewriter API, you can have your cake and eat it too! We’ll replicate a full WordPress experience with comments, top posts, like buttons and a page counter. All on Cloudflare’s free static site hosting platform.

You can check the slides for Jonathan's talk here.

30 min
17 Feb, 2022

AI Generated Video Summary

The Talk covers the historical landscape of web development, the rise of static site generators, the serverless revolution, edge computing, and using Cloudflare services to enhance static websites. It explores the challenges of early web development, the shift to static sites and client-side rendering, and the advantages of server-side and client-side rendering. It also discusses Cloudflare services like Cloudflare workers, KV, durable objects, and HTML rewriter for building fast and minimal hosting solutions. The Talk highlights the use of DurableObjects for analytics and integration, dynamic content on static sites, JAMstack, and the advantages of using Cloudflare Workers for automatic deployment, multiple language support, and combining static pages with JavaScript functions. It introduces the concept of edge computing and the difference between Cloudflare Pages and Workers. It also touches on error handling and the use of HTML rewriter, Cloudflare KVstore, and DurableObjects for managing state and storing dynamic data.

1. Introduction and Topics Covered

Short description:

In this part, John Cooperman introduces himself as a developer advocate at Cloudflare and discusses the topics that will be covered in the talk, including the historical landscape of web development, the rise of static site generators, the serverless revolution, edge computing, and using Cloudflare services to enhance static websites.

Hey, my name is John Cooperman. I'm here today to talk about static first websites. So first, just a little bit about me. My name is John Cooperman. I'm a developer advocate at Cloudflare. I mostly work in the emerging technologies org. So I work on our server-less platform workers as well as our storage, some of our state, our command line utility, things like that. And if you want to find me online, I am jcoop, J-K-U-P on all the social platforms like Twitter and GitHub and so on.

So what we're going to be covering today, starting a little bit of a historical look into like early 2000s Web Dev, a little landscape of what things were like back then. Talking about the rise of static site generators, so like Jekyll and Gatsby and all of these great tools. And then also talking about a little bit of the serverless revolution. So when serverless platform started coming out and how they changed things for both small and large companies. Then we'll get into a little bit about what edge computing is and why it's so important. And in the end, we're going to kind of together use Cloudflare services to decorate static websites with any dynamic content you want. Hence the name of these like static first websites that are also a little bit dynamic.

2. Early Days of Web Development

Short description:

Back in the early days of web development, developers had to run their own application servers and manage their own servers. This involved choosing hardware, software, and dependencies, as well as scaling and load balancing. While dynamic websites like Rails and WordPress offer a lot of functionality, they require regular updates and maintenance to stay up to date.

So back when I first learned web development, this was like kind of a landscape. So there was a lot of like Ruby on Rails, PHP, people doing WordPress. And then almost all of these would also send down a copy of jQuery as well as maybe a library like Backbone.js for interactivity. But the big takeaway is that everybody was running their own application servers. We hadn't gotten into any of these like smart hosting. There was no AWS anything like that. We were just kind of like picking a language, picking a framework, and then doing it ourselves.

And so one of the things that this meant was that when you needed to get your own app running, you needed to get your own server. Whether it was like a full machine or a VPS, you had to allocate resources for your app to run. So this was like a pretty archaic process back in the day where you had to call or contact a web host. You had to go with them and pick out hardware like how much memory you need, how much CPU you want to have. You had to pick out software like what operating system should run on the server, what version of that operating system. Then you had to get your dependencies installed if you needed node or PHP or Ruby. And then if it was a popular application, it meant you had to scale it yourself. So you had to get multiple servers. You had to find a way to load balance between them. If your database was getting too overloaded, you would have to shard it out onto multiple database servers, you had to figure out caching yourself. Basically, if you had a popular application, you had to become an ops person as well.

So the thing that I really liked about this day and age was that all of these things, these dynamic websites, whether it's Rails or WordPress, they're really dynamic and they're really fun. They have these giant plug in ecosystems, all these tools. You can do all this great stuff with just the click of a button or a simple install script. So when I think about WordPress sites, I think of a lot of fun things like they'll list out your most popular posts. You can add a contact form. You can add a like button. You can have comments, a good discussion going underneath your blog post. Stuff like that is very, very easy with these dynamics sites. But there's a little bit of a downside too, which is that these dynamic sites have a lot of power. They're often interacting with your database directly or doing some file system access on your server. And so updating and staying up to date becomes really crucial. And so whether it's staying up to date with WordPress or your WordPress themes or plugins, or even the operating system on your server itself, there's always a lot of work to be done.

3. Challenges of Early Web Development

Short description:

In the early days of web development, there were challenges with security, performance, and scalability. Developers had to keep their systems up to date to avoid vulnerabilities and hacking attempts. Direct database calls required optimization and heavy caching for better performance. Scalability was a costly and complex task, involving load balancing and managing databases.

And if you miss an update, you're very vulnerable, very likely going to get hacked in some way. So kind of reviewing this age of very dynamic web apps where you were building everything yourself was very doable, but there were some issues. Mainly we had a security issue, keeping things up to date or hackers trying to access your file system or your database. Performance was a little bit of an issue. You know, when each user is doing a database call directly, you need to make sure that you optimize your database calls and that you cache heavily. Scalability was very difficult back in the day where you had to just be your own kind of person for load balancing, charting databases, and that quickly got very expensive. And so these are kind of some of the issues that I was always facing when I was building apps back in the day.

4. Static Site Generation and Hosting

Short description:

GitHub introduced Jekyll, a static site generator, and GitHub Pages, a platform for hosting static sites. Static sites have advantages such as being free to host, easy to cache, and not requiring updates. However, they can be boring compared to dynamic sites. Companies like Disqus and social media platforms introduced ways to add interactivity to static sites.

So I distinctly remember back in like 2009, GitHub came out with this pair of offerings. And so the first thing they came out with was Jekyll, which is the static site generator. For those not familiar with static site generators, the idea is that you have all this dynamic content locally. So you have themes and partials, like a header and a footer, and all your blog posts or different pages. And then on your local computer, you run a command, and that will generate all the appropriate HTML files, just flat HTML files, and that's all you upload. And so you're not uploading your database. You're not uploading any scripting languages. You're just uploading plain HTML.

And they also came out with GitHub Pages, which is a platform for hosting these static sites. So you could take your WordPress blog, you could export the pages or the posts, rather. And then you could put them inside Jekyll, hit Jekyll generate, and then upload them to GitHub Pages. And all of a sudden, instead of all the dynamic content, it was just flattening it out, and you were uploading that.

So static sites have a bunch of pros. They're almost always free to host. This is still true, whether you use GitHub Pages or Netlify or Cloudflare Pages, it's very easy to find a free host for static sites. Often, when you find a host, they're already placed automatically onto a CDN. And I think this is because they're just very easy to cache. There's no dynamic data, there's no decisions to be made, you can just put those HTML files on a big range of servers. They don't require any updates. This isn't fully true, of course. If you're using GitHub Pages, GitHub still has to go update their web servers, but it's abstracted away from you, is the important part. You'll never have to go update any software. They're extremely fast. Browsers and servers are great at serving HTML, so it makes for an extremely fast experience. But the downside is they became a little bit boring. We lost a lot of that fun dynamicism that made sites really interesting to interact with.

And so around this time, when people started moving to static sites, companies kind of came up trying to make the static site experience better. So one example is Disqus, which is a comment system where you can just embed some client-side JavaScript on your static site, and it'll hit their servers and load in comments, so people can still interact like they used to. Another example is that social media companies like Twitter and Facebook, they made tweets that you can embed. Facebook made comments that you can replace your comment system on your static site.

5. Shift to Static Sites and Client-Side Rendering

Short description:

They made like buttons that are interactive. A bunch of companies came out with cool social sharing buttons. In Google Analytics, you could embed, again, a little piece of JavaScript on your static site. So the world sort of shifted from rolling everything your own, yourself, to this very safe, very fast static site, and then you would subscribe or pay for these premium services, and so on their servers they would host some of this more dynamic data. So, while this is kind of going on in this space of like, e-commerce or bloggers or news articles, a similar trend is happening in app development.

They made like buttons that are interactive. A bunch of companies came out with cool social sharing buttons. In Google Analytics, you could embed, again, a little piece of JavaScript on your static site. So the world sort of shifted from rolling everything your own, yourself, to this very safe, very fast static site, and then you would subscribe or pay for these premium services, and so on their servers they would host some of this more dynamic data.

So, while this is kind of going on in this space of like, e-commerce or bloggers or news articles, a similar trend is happening in app development. And so, again, app development sort of starts off in this place where everything is built in, you know, PHP or Java or Ruby, and everything is server-side rendered back in this day. We haven't had any real client-side rendering libraries yet. So, HTML is all generated server-side, you use some templating library, like maybe mustache or something like that. And again, just like with static sites and e-commerce, you send down maybe some jQuery so you can do some interactivity after the page loads.

And so, what's really interesting here is that you sort of run into this thing where you've got some pros, but you've got some cons. And so, companies find out that it's really expensive to have a very popular app where you're generating all of this HTML yourself. And so, the first client-side template libraries come out. And companies make an attempt where they move all of this stuff. Here's Twitter as an example. I worked there back in the day. From the server to the client. They're like, oh, this is great. Save all this money. The clients can handle the rendering. It's perfect. They launch this thing, and then they find out that there's actually a lot of drawbacks to client-side rendering, too. Namely, that it's very difficult for slow network connections or low-end devices to be able to render the site. So, they move everything back to the server again. They're like, okay, this is way better. We've got closer access to our databases. We can handle initial page loads are way faster for slow devices. And then better client-side libraries come out like ReactJS. And so, everyone moves all the way back to the client again. You see this. I always refer to it as the pendulum swinging back and forth where everyone goes extreme one way, extreme the other way, back and forth, and back and forth.

6. Server-side vs Client-side Rendering

Short description:

There are tradeoffs between server-side rendering and client-side rendering. Server rendering is better for SEO and has faster initial page load, but requires more resources. Client-side rendering is cheaper and has faster subsequent page loads, but may not perform well on slow networks or older devices. The landscape has changed with the rise of cloud providers and the serverless revolution, making services cheap, easy to scale, and fast. Cloudflare operates at the edge, taking advantage of these changes.

So, what's really happening here? It seems a little bit silly, but it really isn't. So, there's kind of two things going on over the years. One, there's very real tradeoffs between server-side rendering and client-side rendering, and sometimes the pendulum over corrects a bit. And two, the landscape underneath really has changed over the years. Server-side rendering today is not what it was 10 years ago. So, for those that haven't done much kind of reading back and forth, the basic kind of pros and cons between server rendering, client rendering.

Server rendering is better for SEO, because the search engine robots can crawl the pages. They don't have JavaScript, so they can't use JavaScript to render content. Your initial page load will always be a lot faster, because it's already there, ready to go on the server. So, all you have to do is send down some HTML. But you're definitely paying for a lot of servers, a lot of databases, you know, you're doing a lot of work on the server. Client-side rendering, on the other hand, while the initial page load might be slower, the subsequent page loads are a lot faster. This is where you kind of see the landscape change with the progressive web apps start becoming very popular, where maybe it's okay if it takes an extra second to load the app, because you're meant to spend a lot of time there. So, once you get to, everything you do, you know, you're interacting, you're messaging, you're checking new stuff is a lot faster, because you're not doing a full page refresh. It's a lot cheaper, you save a lot of money, but again, the downside is it's very difficult for people on slow networks or older devices to be able to handle rendering this entire app.

At the other hand, while the tradeoffs are very real, the landscape has changed. And so, back in the day, finding a web host was almost like a mom and pop shop, you could call around, find a place, maybe a local place, but these days we've seen this rise of these big cloud providers. So, you see your Google, your Amazon, Microsoft, CloudFlare, providing these cloud storage services with extremely high uptime and extremely competitive pricing. At the same time, we went through this bit of the serverless revolution. So, whereas before you had to really know a lot about what you were buying or what you were renting, nowadays, we've kind of abstracted away the decisions about hardware. You don't have to worry about that. Operating system, you don't have to worry about that unless you need to. Scaling has become very easy. You just pay for how many requests to use. So, if you get very popular, you just pay a little bit more. If you have a slow month, you just pay a little bit less. And with some of these new solutions, you don't even have to worry about location. Your code deploys immediately to the whole edge network. So, as this kind of back and forth has been happening, services became very cheap, very easy to scale, and very fast, which is a big incentive and really changes the kind of perspective when you're choosing between server and client render. So, when we're thinking about this landscape change in terms of Cloudflare, I think the important thing is to keep in mind as we build what we're about to build is that everything is done at edge.

7. Cloudflare Services and Worker Sites

Short description:

Your code gets deployed to hundreds of data centers, as does your storage. Requests are very cheap. Cloudflare provides Cloudflare workers, a serverless platform that runs at edge. They also offer a key value store called KV, durable objects for persistent JavaScript objects, and HTML Rewriter for parsing and making dynamic changes to HTML. When building a fast blog with WordPress features, you can choose between a full dynamic app or a static site host with serverless functions. The workflow involves using a static site template, installing the Cloudflare CLI, initializing a worker's site project, and publishing it. Worker sites take HTML files and store them in Cloudflare KV, generating a JavaScript worker to serve the files from KV. This provides a fast and minimal hosting solution.

So, your code gets deployed to hundreds of data centers, as does your storage. Requests are very cheap. Our free plan gets you millions of requests per month. WebSocket supports. So, you can choose, depending on the app that you're building, between an HTTP response and a WebSocket connection. We can do HDL rendering at edge, but we can do HDL parsing at edge, which we're going to get into in our example, and we have two distinct offerings for ways of having some application state or some storage that can be very quick for you, too.

So, before we get into building, I just want to cover some of the Cloudflare service terminology for those not familiar, because I'm going to be using their kind of official product names going forward. So, when I refer to Cloudflare workers, that's our serverless platform, so you deploy your code, which we would call a worker. It runs at edge, meaning it runs in all of our data centers, and it has the format of it takes in a request and it returns a response. We have a product called KV. That's our key value store that also runs at edge. It's very fast to read, since your data will, the value and your key will live at all of the data centers, but it is eventually consistent, meaning that if you update it, if you do it right, it takes a little while for it to propagate to all of the edge servers. We also have durable objects, which is another storage offering. These are persistent JavaScript objects, so they persist to disk, and they're just this one single instance, so they're not replicated to edge. So, they're a little bit slower reads, but they open up a whole slew of things that you can do pushing a lot of dynamic data. And then the last thing is we have a product called HTML Rewriter, and this is an HTML parser that runs at the edge, so you can not only render HTML, like markdown to HTML, which you've always been able to do, but you can actually scan the HTML and make dynamic changes. Anything that you would be changing, if else, with React, you can do that kind of stuff with our HTML Rewriter.

So, a little food for thought before we get into it. If you were asked to build a blog and you needed to be really fast, really perform it, but you also wanted to have some of these nice WordPress features, like a popular post section, a like counter on each post, or the ability to add comments, what tool set would you reach for? Would you instantly go for a full dynamic app, like a WordPress instance, or some kind of CMS? Or would you try to put something together, maybe with a static site host, plus a few serverless functions and kind of try to stitch it together? So, our workflow that we're going to be using today is take any static site template, so this could be like Jekyll or Hugo, Eleventy, Gatsby, anything that produces a bunch of HTML files. You can even just write the HTML files yourself, it really doesn't matter. Install the Cloudflare CLI, which is called Wrangler, and then we're going to initialize a worker's site project, which I'll get into in the next slide, and then we're going to go ahead and publish it.

So, what is worker's site? So, when you think about hosting these static sites, like GitHub Pages, Netlify, Cloudflare Pages, the basic idea is that you take your GitHub project or your Bitbucket project, and you point it at one of these services, and somehow, behind the scenes, the service runs a build, grabs all of your static sites, and starts a web server, and now when you go to that URL, it routes you. You know, just behind the scenes, it's doing everything you'd expect it to, right? And so, there's a lot of ways that you can accomplish this, but one way you could do it, if you wanted to build your own experience, would be using worker sites. And so, what this will do is, it'll take that folder full of HTML files, and it'll stick each HTML file in Cloudflare KV, our Key Value Store. And so, if you have an about.html, it would make a new entry in KV, the title would be about.html, and the value would be the actual HTML inside that file. And it'll do that for all of your files, and so what you'll end up with is, a bunch of KV stores. Each one's name is the file name, and the value is the HTML itself, and then it'll also generate a simple JavaScript worker, which will just listen for all incoming traffic, pluck out that route, that file name, and go fetch it from KV and serve it. And so you can see, after we just, I grabbed that 11T base project, I ran worker sites on it, and then I deployed it, and you can see I have, this is my KV dashboard. And on my KV dashboard, I can see all of my little file names as the keys, and the values are actual raw HTML, or CSS, or XML. And then, accompanying that, I get this very minimal worker.

8. Using DurableObjects for Analytics and Integration

Short description:

This section discusses using JavaScript to retrieve assets from the KV store and return them as a response. It introduces DurableObject storage, which allows for the creation of persistent JavaScript objects. The text explains how to use DurableObjects to track analytics, such as the number of times a path has been hit. It also mentions sorting the analytics and using DurableObjects for likes. The section concludes by discussing two options for integrating everything: adding a client-side script tag to the static site or performing all operations within the worker.js file.

So, this is just some JavaScript. It takes the event request, and it goes and it gets the asset from the KV store, and adds a few headers, and then it returns it as a response. And so basically, if you take your Hugo site, your Jekyll site, your 11T site, you run the wrangler command on it, and you hit publish, you get exactly what you'd expect the thing deploys to a Cloudflare link, but behind the scenes, it's just kind of important to know that it works between this KV store and this worker.

All right. So, now we can start having some fun here. We're going to use the DurableObject storage thing. So these are persistent JavaScript objects, and we're going to start making some of our own things like a top post, a likes count, or something like that. So, as far as syntax goes, they're a JavaScript class, they're a constructor. You can see in the constructor, we're basically saying this state storage, this is a DurableObject API, get the analytics storage, and keep it in memory. And if there is no analytics storage, then initialize it to an empty object. And then what we're going to be doing in the background, we're going to hit this on every request and we're going to say, okay, get the path that the user's trying to hit. And if that path has already been hit before, increment the number of times it's been hit by one, otherwise make a new entry with that path and set it to one. And so, what we'll end up with here is just a big analytic subject about each of our paths and how many times they've been hit. So, in this next slide, we can kind of see in comments what it will basically look like. It will just look like this big object where it has my first post was hit 33 times, my second post was hit 200 times, etc. And then we can just run a simple sort on it. So, we sort it by value and kind of wanted to, we could slice off the top five and boom, we have this durable object that basically is doing your top five posts. We can do a very similar thing with likes. They're way simpler. You can have a single durable object for each path, for each page that you have, and then the likes would just get instantiated to a simple number. So, you could say this has zero likes. When people click it, you just increment the number. So, we've got this worker that's serving our requests. We've got all of the pages themselves living in KB. How do we put it all together? So, option one is we could do it very normally. We could add a simple frontend client side script tag to our static site. So, the static site would load and then the script would execute and that script could grab DOM elements, hit the durable object to get either the number of likes or the top five posts and then use any client-side templates language to override that content. So, you'd see a site loads really quickly with some spinners and these async requests kick off and eventually populate the site. But the cool thing that doing everything at edge means really you can do dynamic things in the same amount of time that it used to take and even still takes to do static things. And so, one thing we could do is in this little worker.js that's generated, we could actually do everything right there.

9. Dynamic Content and Static Sites

Short description:

We can grab the HTML file from the KB store, interact with durable objects, get the top post and likes, and use the HTML parser on the server to fill certain divs with data. The worker grabs the blog post, durable objects, and rewrites the HTML per request. Despite dynamic content, response times are still fast. The takeaway is that static sites have become more capable, easier to build, and edge computing allows for dynamic content at the same speed as static content. Taking a static-first approach provides resilience and affordability without sacrificing functionality.

So, we could grab the HTML file from the KB store, we could also interact with our durable objects, we could get the top post, we could get the likes, and then we can use the HTML parser still on the server in this request to parse out certain divs like top posts and fill it with that top post data. So, we can do that all as the request is waiting to process and still do it very quickly.

So, a little bit of an architectural diagram here. We have got all of our users. They hit the cloud. The worker grabs the blog post from KB, grabs the durable objects from likes and analytics, and then rewrites the HTML on the fly per request before sending it down. I really like this tweet from one of the founders of the Remix app. Saying that, I know it's silly, but I'm getting 130 millisecond response time even doing all of these server mutations. So, the server's doing fetches, mutations, everything like that. Still 130 milliseconds.

So, here we go. We made our site with popular posts. It's also got likes. It's also got comments. All that dynamic stuff. And you can kind of see here from my Chrome DevTools that we're still getting responses of like 50 to 80 milliseconds despite doing all of this dynamic content. So, the takeaways here are that static sites have capabilities that of web apps have never been more possible. Never been easier to do. Edge computing means you can do dynamic content about as quickly as you were doing static content. And by taking the static first approach, your site is going to be resilient and cheap but you don't have to sacrifice functionality.

Thanks so much. Hey, John. Welcome. Thanks a lot for such a nice talk. Yeah. Thank you for having me. Yeah. So, the results are in. And 68% say API. But...

10. JAMstack and Cloudflare Workers

Short description:

Yup. That is the correct answer. It's kind of funny. I was talking with my coworkers. All these years working on it, I didn't know that JAM was an acronym. But yeah, we are happy. 68%, 69% of people know the right answer. Yes. API. It was really nice to see this overview of our evolution of web from the 2000s to 2022. So yeah, it's such a nice to see all the transition into static CSR, SSR and the flipping between them. So, okay, so, I have a few questions for you. So, okay, so one question I see is, why should we use Cloudflare workers? Yeah, so I think if you're looking for a serverless offering, they're all great, I really like all the competitors as well.

Yup. That is the correct answer. It's kind of funny. I was talking with my coworkers. All these years working on it, I didn't know that JAM was an acronym. And so, one of my coworkers was like, you should ask what the A stands for. And I was like, I didn't know that any of them stood for anything. But it looks like 68% of people know a lot better than me. But yeah, it's JavaScript, APIs, and Markdown, Jam, Jamstack. It's actually very easy to confuse between API and application. Yes. When you're saying Jamstack. I figured that was a tricky... That was my deceptive answer. My trick answer was application. Okay. But few people also mentioned Architect and Apache. So yeah, I wonder. Yeah. I mean, I could see any of them working. But yeah, it was interesting for me. It's interesting. But yeah, we are happy. 68%, 69% of people know the right answer. Yes. API.

So, it was really nice to see this overview of our evolution of web, I would say, from how it was in the 2000 to we are in 2022 now. So yeah, it's such a nice to see all the transition into static CSR, SSR and the flipping between them.

So, okay, so, I have a few questions for you for sure. So, okay, so one question I see is, why should we use Cloudflare workers? Yeah, so I think if you're looking for a serverless offering, they're all great, I really like all the competitors as well.


Advantages of Cloudflare Workers

Short description:

Cloudflare workers offer the advantage of automatic deployment to multiple locations, ensuring fast results and eliminating cold starts. They support multiple languages and provide features like bot detection, DDoS prevention, and image optimization. Cloudflare also allows the combination of static pages with JavaScript functions, enabling dynamic functionality on top of static sites.

But I think being edged by default, so you don't have to worry about location, and you don't have to pay extra for multiple locations. When you use Cloudflare workers, they automatically deploy to all of our locations, so your users are always getting very fast results. And so with that comes incredible speed, we don't have cold starts, like a lot of the VMs do, your code is always running in v8. And then we have we have full support for Rust, TypeScript, JavaScript, so yeah, I'd say they're really fast, they run everywhere, they're really cheap and support a lot of languages.

Awesome, yeah. So I think you mentioned lots of benefits of using Cloudflare workers already. So Tushina had a question, like, what is the advantage of Cloudflare workers over GitHub pages? Oh, so right. So we have like Cloudflare pages as our static site offering or using workers with worker sites. I don't want to get too in the weeds, because I love GitHub pages, I think that they're all great options for hosting your static site. The big one that I see, I guess there's two, two ends that I see with using our thing. One is, once you're in our kind of sphere, you can quickly enable our other products. So you can quickly add like our bot detector DDoS prevention, you're already on our CDN image optimization, JavaScript optimization, like we have like 50 plus products. So once you're on our site, it's very easy to just start toggling those on and off. And the other thing is that we're adding support for combining, you know, with GitHub pages, you just have your static pages, your HTML, your JavaScript, your CSS. With Cloudflare, you can also upload JavaScript functions. So you could very easily like add a header globally or talk to a database before return, you know, as soon as you want to do anything dynamic on top of your static site, that's where we really shine.

Yeah, it's a little confusing, because it's like is two computers edge is three edges, five edge, and that's like a very ambiguous. But in our case, we're talking about hundreds of data centers. So, okay, so we have another question.

Introduction to Edge Computing

Short description:

Edge computing is a concept where data centers are distributed all over the world, allowing for faster response times. Instead of having visitors access data from a single location, edge computing ensures that code runs in the data center closest to the user. This results in fast response times, regardless of the user's location.

Please do let me know if you run into anything.

Yes. So I wanted to like, could you explain maybe, just from a beginner perspective, what is edge computing? Yeah, I get this one a lot. So basically, if you think about kind of older style of hosting your application, you'd always have to pick a location, right? So you would buy or rent a server and you would pick from a dropdown, New York or LA or whatever, which means so let's say you pick New York, then if you have visitors in Japan, then they're all having to come all the way from Japan to New York to get your data. And so what the idea of edge computing is that we have lots and lots of data centers, hundreds of them all over the world. Every time you make a new worker, any function you make it's uploaded to all of them. And then when a user hits your website, they will run the code that's closest to them. And so that's what gets us these like really, really fast response times, even if it's doing dynamic data is that you're very likely hitting a data center in your region, almost always no matter where you're from. Yeah, it's a little confusing, because it's like is two computers edge is three edges, five edge, and that's like a very ambiguous. But in our case, we're talking about hundreds of data centers.

Difference between Cloudflare pages and workers

Short description:

Cloudflare workers is a serverless platform where you can write functions to handle requests and perform various tasks. Cloudflare pages, on the other hand, is a static site hosting platform that allows you to host static sites and also includes a functions directory for any dynamic elements. Workers are the functions, and they can be used in conjunction with pages if needed.

So, okay, so we have another question. And they want to know what is the difference between Cloudflare pages and Cloudflare workers? Yep. So workers is our serverless platform. So you write functions that take a request in and return a response. Those can do anything they can talk to databases, they can generate HTML, whatever they want. Cloudflare pages is built on top of that, and it's our static site hosting platform. So similar to Netlify or GitHub Pages. And then with Cloudflare pages, you can have a functions directory where you put any dynamic stuff that you want. So, pages is the static site host, workers are the actual functions, and then you can have workers with your pages project if you need them.

Error Handling and HTML Rewriter

Short description:

Is it possible to keep other statements in between try, catch, and finally blocks? Let me take that one offline. John explains HTML rewriter, an API that can parse HTML and give selectors. It runs in all data centers, allowing for parsing and updating HTML at the edge. Cloudflare KVstore and DurableObjects are used for managing state, with KV being fast for reads and eventually consistent for writes, while Durable Objects offer instant writes but slower reads. KV is suitable for storing dynamic data like blog posts, while Durable Objects are ideal for applications requiring fast writes, such as video games or chat rooms.

Okay. So, I see another question which is like, is it possible to keep another statements in between try, catch, and finally blocks, I think, relates to some code? I'm not sure on that one. Let me take that one offline, I'm not exactly getting what the question is. Yeah. I think it's related to some error handling.

So, okay, sure. So, John, you talked about HTML rewriter, actually, I was pretty much interested in specifically that, so could you expand a little bit on that? Yeah, it's one of my favorite things we have. So in essence, it's just a API that can parse HTML and give you selectors like you're used to. So you can select a class or an ID or a tag, and then you can have event listeners for every time you hit a div, call this function basically is what it does. And then in that function, you could replace the div with a span or something like that, or replace the content. But the cool thing is it runs in all of our data centers, so you could do it at edge. So if you're having, I'm in Florida, so I'll hit a data center in Florida, that data center is capable of parsing and updating the HTML. So yeah, it's like a full compliant HTML parser that runs on the edge. That that is pretty interesting actually. I really like it.

Okay. So just quickly, another question, what's the difference between Cloudflare, KVstore and DurableObjects, and when should we use which one? Yeah, that's great. So there are two, they're very similar. They both are used for managing state. KV is at the edge, so it's in all, many hundreds of our data centers, which means it's really fast reads because it's right there in your data center. But when you write to it, it's eventually consistent, meaning that if I put something in there and say, Hello world, and then I change it to say Goodbye world, it'll take a while to update all like 300 of our data centers with the new message. So really fast read, slower to update after being written to. Durable Objects is not at edge. It's just a single instance. So a little bit slower reads, but instant writes. So if you wanted to build like a video game, Google Docs, chat room, anything that's very, very fast writes, you would use Durable Objects. If you wanted to like store some data like blog posts or something like that, KV is a way better way to go. So KV, if you can, if you need something really dynamic, then Durable Objects is perfect for that.

Thank you. Yeah. It really makes much more clear for me now. Thank you once again, John, for being with us today and sharing all your knowledge with us. So for the audience, you can now continue to the special chat and join John in the discussion room, Cloudflare workers discussion rooms, and meet him there and ask questions. If you have any over there and thanks a lot, John, once again. Thank you. Thanks for having me.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
React Advanced Conference 2021React Advanced Conference 2021
36 min
Living on the Edge
React 18 introduces new APIs for rendering applications asynchronously on the server, enabling a simpler model for architecting and shipping user interfaces. When deployed on edge networking platforms like Cloudflare Workers, we can get dramatic performance and user experience improvements in our applications. In this talk, Sunil will demo and walk through this new model of writing React applications, with some insight into the implications for data fetching, styling, and overall direction of the React ecosystem.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js ( Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow ( 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.