Static first websites with Cloudflare Workers

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.

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.

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.

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.

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.

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 twitter.com, 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.

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.

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.

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...

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.

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.

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.

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.

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.