💻 JAM on the Edge with Cloudflare Pages

Hey everyone, welcome to Cloudflare TV and welcome to my talk called Jam on the Edge with Cloudflare Pages. So today we're going to learn a lot about how Cloudflare Pages makes it super effortless to create and deploy a statically generated website and get in front of your users as quickly as possible. So a little bit about me. My name is Ado Kukic. I actually lead the developer advocacy team at MongoDB. Prior to that, I led the developer evangelism team at Auth0. And at both of these companies, my job is to make developers' lives easier by giving them the knowledge and tools to be more effective. And I myself am a full stack software engineer. I have been programming front-end, back -end applications for the last 15, 16 years. And I've worked with, you know, React, Angular, Node, Go, and then MongoDB and traditional SQL as well. So enough about me. Let's get into the fun stuff. So before we get into why you would want to use Cloudflare Pages, I just want to kind of set the ground, set a stage for what the Jamstack is, if you're not familiar so that we're on the same page before we dive into it. And a question I have here is, how do you get the fastest website in the world? And, you know, to create a really, really fast site that loads super fast for all of your users, you would simply just use HTML, right? No external resources, no JavaScript. You would just write markup, deploy it on a CDN, and your page would load super, super quickly. But it probably wouldn't be a, you know, a very good application because it wouldn't have a lot of interactivity. It wouldn't have a lot of function. So this is kind of where the Jamstack comes in. And if we look at the Jam acronym in Jamstack, it stands for JavaScript APIs and Markdown. And essentially what this means is when we build and deploy a Jamstack application, you know, the first thing that we're going to do is we're going to add JavaScript to it to provide functionality within that client application. Our Jamstack, our statically generated website, is going to live entirely in the user's browser. So when a user comes to our application, they should have all of the functionality needed to complete their actions, place an order, leave a comment, sign up for something, all within the client without having to rely on a backend server. And how are we going to provide this functionality? That's where APIs come in. And, you know, this can be internal APIs, you know, it could be a functionality that we deploy on Cloudflare Workers or, you know, AWS Lambda, Google Cloud Functions, any sort of backend system that is going to give us our app, our internal functionality, or we could utilize, you know, SaaS endpoints to provide that functionality. So things like, you know, Twilio for messaging or Stripe for payments or, you know, Azure for authentication and so on and so forth. So our APIs are going to act as microservices and provide the functionality to our client application that is just serving static HTML for the most part. And then finally, the M in JAMstack stands for Markdown. And traditionally, you know, most statically generated websites, the static content doesn't change often. And, you know, Markdown is super easy to work with. So, you know, there is a strong preference for using Markdown in generating your static content. But again, all of these are, you know, more, they're not kind of, you know, set in stone, you have to use JavaScript and APIs, and you have to use Markdown. But they're just kind of good starting stones, you know, starting paths in the JAMstack journey. And, you know, while we could, and some people do, you know, prefer to write their entire website, their entire application, with just static HTML, we have a lot of tools that will actually simplify that process for us. And there's tools in the JavaScript ecosystem, like Next.js, for example, which is a React-based framework that gives you all sorts of functionality, with one of them being, you know, static site generation. There's Hugo, which is a Go-based static site generator, which I am a big fan of, personally. And, you know, I feel like I have to mention Jekyll, which is really what kicked off the static site generation movement altogether way back in 2007 or 2008, I believe. But, you know, these three are just three of the many, many frameworks we can use to build JAMstack apps. Now, let's kind of take a look at why JAMstack is preferred for many types of applications these days. So, if we look at a traditional web application, this is essentially how it works. You know, you have your client, which, for the most part, will be your browser, either on your mobile device or on your laptop or desktop computer. When you type in a website, let's say AutoXYZ, for example, if we had a traditional application, our browser, our client, you know, at the beginning, when we make that connection, we don't have anything to serve. We have to go to our web server and say, hey, we have a request for the AutoXYZ web page, you know, what do you have for me? And then the web server might talk to an app server or might talk to a database directly and say, hey, here's the homepage content, let's pre-render it, let's create that content, you know, on the fly, and then we'll serve it to the client. And there's all, you know, this is kind of an oversimplification, but typically that's what happens for every page that we load. Instead of kind of having that content pre -generated, pre-computed, every single time somebody lands on our page, we have to do that computation, go to the database, get the content, go to CMS, go to an external API, kind of combine all that content, render it, and then serve it to our browser. And, you know, if you worked with WordPress in the past, which is, you know, one of the most popular traditional kind of web application frameworks, you might have run into this. So your application gets a bunch of users, you know, you write a really good blog post, everybody wants to read it, but since your application has to go to the database every single time, render that content and serve it, if you're, you know, if you don't have the resources to render all of that information, to scale it up, you're probably going to get an error message like this saying that, you know, something broke down, there's too many people connecting to the database, we can't keep up with demand. And that's kind of where Jamstack comes in, right? When we create a statically generated website, all of the content is pre-computed. So our blog posts, you know, all of the HTML for them, all of the styling, we already know it at build time. We know what it's going to look like, we know what it's going to render, and we render those pages, throw them up on, you know, Cloudflare CDN or another CDN. And then when our application goes to, or when a user goes to access our application, in their browser, they type in auto.xyz, and we get the request to serve the homepage for auto.xyz, we already have that content pre-computed and understand what, you know, what needs to be displayed, and we can send it right off the bat, and the user sees the page loads almost instantaneously. And then we can utilize microservices like Cloudflare Workers or other technologies or, you know, other SaaS APIs to add additional functionality. So, you know, we might just render my blog post, all of the content that I've written, but then we might make a subsequent call once the page is loaded to get comments for that blog post, or social share links, or any sort of additional functionality that we might want to provide. So, that's kind of a primer on Jamstack and how it works, but why would we want to use Cloudflare Pages for our Jamstack or statically generated websites? Well, I have a couple of reasons. So, the first one is, you know, the first one is that, you know, utilizing Cloudflare Pages, we get the benefit of Cloudflare's edge network, meaning that our deployed website is going to be milliseconds away from our end users. You know, Cloudflare has so many data centers and have been kind of the, you know, top tier executor when it comes to edge computing and really getting in front of, you know, getting in front of users where your users are. So, as soon as you deploy your application to Cloudflare Pages, it gets replicated to all the data centers, and you don't have to proxy your connection to a different provider. It's all, you know, within the Cloudflare ecosystem. Next is their really amazing preview control, allowing you to easily manage access to your staging branches to only trusted parties. So, you know, on the Cloudflare Pages kind of marketing landing page, there is a section that talks about, you know, deploy early and deploy often, and with other, you know, static generating platforms, you have to manage all of the different branches. You have to manage access for them. Cloudflare makes this so easy, and we'll see that in a demo in just a second. And then finally, you get the best of Cloudflare built in with Cloudflare Pages. So, things like HTTP3, quick image comprehension, image compression, and like email address obfuscation, and many other features, you know, the latest and greatest web standards and security features, just come out of the box and integrate seamlessly into Cloudflare Pages. But, you know, let's see it in action. Instead of talking about it, let's go ahead and deploy a Cloudflare Pages app and see how easy it really is. So, let's jump into the demo. So, here I am on the Cloudflare Pages landing page, and, you know, I'm not going to read any of this stuff. I already know that, you know, I want to build a Jamstack app. I have a Jamstack application that I want to deploy. I'll just hit the sign-up button, and since I'm already logged in, it's going to take me to the Pages section, where I can create a new project or view my existing one. So, to create a new static deployment, I'll first need a Jamstack application, a statically generated app, and again, this can be with any sort of framework. It could be with Next, it could be with Jekyll, Hugo, or it could just be, you know, a custom-made HTML static website that you want to deploy yourself or write yourself. So, I'll hit the create a project button and choose the repository that my application lives in, and here, you know, I've connected my GitHub account and I've given it access to two repositories that host static websites, and I'm already using my blog, so I'll use the second one, and then I will hit begin setup. From here, it's just going to ask me what the build command it should run when deploying the application. So, if you don't have a framework and if you just have static HTML pages, you know, you don't have to add a build command. You just point to the directory, but since I am using Hugo in this instance, I'll just use the framework preset for Hugo, and it's going to give me the default command, which is Hugo, and the default Hugo output directory, which is public, but if I wanted to change any of that, I could, and I will make a change here and just say I also want to minify my CSS, my JavaScript at build time, so I will add that minify command, and then finally, since I am using a, I want the latest and greatest version of Hugo, I'm also going to add an environmental variable called Hugo version, and I'll set it to the latest deployment of Hugo, so this way, when we build the application, it's going to run, it's going to pull down the latest version of Hugo instead of the default one that comes with top layer pages. From here, all I have to do is hit the save and deploy button, and we are off to the races. So, this is going to take a couple of seconds to get started. You know, my application is now initializing the build environment. It's going to clone the Git repo, build the application, and deploy it. I don't have to do anything from this point on except just wait, but, you know, instead of waiting for two, three minutes, let's go ahead and look at the deployed site and some of the cool features while this webpage is deploying. So, I'll go back to my pages home page and take a look at my deployed blog here. I'll visit the website just to make sure that it's running, and it is. So, here's my website. You know, you can click on the blog post. They all load really, really quickly, and I'm really happy with it, and we can click into it to see some of the deployments that I've had and how my environment is set up. So, I have a couple of preview branches. I have, you know, a couple of production branches that I push content out to, and if I look at the build stats, I can see that my entire application, the last time I built it, went from, you know, went from the old version to the new one in a little over a minute, and that's to, you know, initialize the build environment, clone the GitHub repo, get the latest changes, build the application, and deploy it to the Cloudflare's global network. All of that took one second over a minute, which is really, really amazing, but from here, you know, I have my custom domain set up for my website, and then within the settings, I have my access policy, which is, you know, one of the coolest things that I think Cloudflare offers with their pages integration. So, with this access policy, every time I create a new branch and deploy my application, it's going to automatically create and deploy a branched version from the branch that I have, and by default, you know, if I don't set the access policy, anybody that has a URL will be able to access it, but I want to limit that, so I enabled access policies that only people with my email address are able to see it, but I could easily add additional members, and to show you how this works, if I go back to my deployment section and I try to access this, I'm going to zoom in a little bit, I try to access one of these preview environments, like let's say this one right here. When I go to open it, I'm going to get the application because I'm already logged in, it knows who I am, but if I go and try to access this preview URL in a different environment, in a different browser where I'm not logged in and authenticated, we'll just open it up in incognito here, I'm going to get this Cloudflare access message asking me to get a login code emailed to me before I'm able to access it, so if I put in my email address, say contact.auto.xyz, send me a code, I'm going to get an email sent to me immediately with this code, so let's go back into the browser here, I'll open up my gmail really quickly, go into contact, and here is the login code, it's 806-127. I'll put in 806-127, sign in, and I will be able to see my preview environment, which has this Cloudflare post that I am testing out. So far, so good, but here I will close out the incognito tab to clear out that session, and I'll try to access it again, and this time I'll get, you know, I'll get the same prompt asking me to email a code for myself so that I can access it, and if I put in, you know, a different email address, let's say my, you know, MongoDB one, it'll say that a code has been emailed to me, but it actually will not, because Cloudflare access is going to check the list of users that I have allowed, and since my MongoDB email address hasn't been kind of allowed to view my personal website's access, the email code is never going to be sent out, and I'm not going to get a code or be able to view the site, so if I just put in something and try to sign in, it's going to give me the message of that account does not have access. So that's Cloudflare pages access management, or access policy. The other really cool thing about having Cloudflare pages built into the Cloudflare platform is that you can have web analytics, kind of privacy-focused web analytics that don't require you to add any sort of JavaScript snippet to your application built in immediately, so all we have to do is enable web analytics, and we are off to the races, so these changes will take effect on the next deployment, but then we can view our kind of simplified web analytics for our domain and see, you know, where users are coming from, what pages they're viewing, how many pages, and so on and so forth. So all of this is enabled with simply just one click, and the managed policies work pretty much the same way. On the built-in deployments, you know, I can have all of the non-production branches deployed or a subset of them. Again, my build configuration is Hugo Minify, and my Git integration is to my personal GitHub account. And then for environment variables, I can add as many as I want and need, and I can even have different environment variables depending on if I'm in production mode or in one of the previous stages, because in production, I might want, you know, some more, for example, like CSS purging with the Tailwind CSS framework. I might want to do that in production to decrease the size of my pages, but in staging, I might want to see everything to make it easier to debug any issues. So that's pretty much it for pages. Let's go back here and see if our megangrid.net website is deployed, and it looks like it's still in progress. If we try to visit the site, we can actually see that it is deployed. It's just not updated, and it works just the same. We can click on the blog, we can view any of the content, and it all loads super, super quickly. And we can see that we can see our deployment. We can set up a custom domain for it, change any of the settings, our build and deployment, our, you know, sorry, our build and deployment, access policy, and so on and so forth. So that is GitHub Pages in a nutshell. Let's go back to the slides and summarize. So, you know, in conclusion, Cloudflare Pages makes it really, really effortless to deploy and manage your static website in minutes. And again, you can use any sort of framework, any sort of statically generated framework, whether it's Next.js or Hugo, Jekyll, to build your site and build your application. And then Cloudflare will take care of managing all of the deployments, giving you, you know, really good previews and deciding what you want to actually deploy. The built-in collaboration with as many users as you need makes it very easy to, you know, test out content, make changes constantly, make changes frequently, and ensure that it doesn't get, you know, leaked out or that the content is available, you know, in kind of that pre-production stage to parties that shouldn't maybe see it yet. And then finally, you know, my most favorite feature of Cloudflare Pages is that it has a really, really generous free tier, allowing you to host unlimited sites with requests and bandwidth for free. And then, you know, when you're ready to have additional sites, if you need more build minutes, you know, more concurrent builds, then it has, you know, very Cloudflare -like pricing of, you know, for pro users and then for enterprises. And with that said, you know, that's pretty much all I had for Cloudflare Pages. I just wanted to do a quick introduction to Cloudflare Pages and the Jamstack and hopefully convince you to give it a try. I have been using Cloudflare Pages for the last three to six months. Prior to that, I was using Cloudflare Workers to deploy my static pages. And while that worked, the Cloudflare Pages is much, much, much, much better in my opinion. So thank you. If you have any questions, any feedback, you can either email us at the link on Cloudflare TV, or you can follow me on Twitter at CookieChado, and I will be happy to continue the conversation there. Thank you again, and have a great rest of your day. Everybody should have access to a credit history that they can use to improve their situation. Hi, guys. I am Tiffany Fong. I'm Head of Growth Marketing here at Kiva. Hi, I'm Anthony Brutas, and I am a Senior Engineer on the Kiva Protocol Team. Great. Tiffany, what is Kiva, and how does it work, and how does it help people who are unbanked? Micro-lending was developed to give unbanked people across the world access to capital to help better their lives. They have very limited or no access to traditional financial banking services, and this is particularly the case in developing countries. Kiva.org is a crowdfunding platform that allows people like you and me to lend as little as $25 to these entrepreneurs and small businesses around the world. So anyone can lend money to people who are unbanked. How many people is that? So there are 1.7 billion people considered unbanked by the financial system. Anthony, what is Kiva Protocol, and how does it work? Kiva Protocol is a mechanism for providing credit history to people who are unbanked or underbanked in the developing world. What Kiva Protocol does is it enables a consistent identifier within a financial system so that the credit bureau can develop and produce complete credit reports for the citizens of that country. That sounds pretty cutting edge. You're allowing individuals who never before had the ability to access credit to develop a credit history. Yes. A lot of our security models in the West are reliant on this idea that everybody has their own personal device. That doesn't work in developing countries. In these environments, even if you're at a bank, you might not have a reliable Internet connection. The devices in the bank are typically shared by multiple people. They're probably even used for personal use. And also, on top of that, the devices themselves are probably on the cheaper side. So all of this put together means that we're working with the bare minimum of resources in terms of technology, in terms of a reliable Internet. What is Kiva's solution to these challenges? We want to intervene at every possible network hop that we can to make sure that the performance and reliability of our application is as in control as it possibly can be. Now, it's not going to be in total control because we have that last hop on the network. But with Cloudflare, we're able to really optimize the network hops that are between our services and the local ISPs in the countries that we're serving. What do you hope to achieve with Kiva? Ultimately, I think our collective goal is to allow anyone in the world to have access to the capital they need to improve their lives and to achieve their dreams. If people are in poverty and we give them a way to improve their communities, the lives of the people around them, to become more mobile and contribute to making their world a better place, I think that's definitely a good thing. We're betting on the technology for the future, not the technology for the past. So having a broad network, having global companies now running at full enterprise scale gives us great comfort. It's dead clear that no one is innovating in this space as fast as Cloudflare is. With the help of Cloudflare, we were able to add an extra layer of network security controlled by Allianz, including WAF, DDoS. Cloudflare uses a CDN and so allows us to keep costs under control and caching and improve speed. Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it, and they've also been willing to throw those logs away. I think one of our favorite features of Cloudflare has been the worker technology. Our origins can go down and things will continue to operate perfectly. I think having that kind of a safety net, you know, provided by Cloudflare goes a long ways. We were able to leverage Cloudflare to save about $250,000 within about a day. The cost savings across the board is measurable, it's dramatic, and it's something that actually dwarfs the yearly cost of our service with Cloudflare. It's really amazing to partner with a vendor who's not just providing a great enterprise service, but also helping to move forward the security on the Internet. One of the things we didn't expect to happen is that the majority of traffic coming into our infrastructure would get faster response times, which is incredible. Like, Zendesk just got 50% faster for all of these customers around the world because we migrated to Cloudflare. We chose Cloudflare over other existing technology vendors so we could provide a single standard for our global footprint, ensuring world-class capabilities in bot management and web application firewall to protect our large public-facing digital presence. We ended up building our own fleet of HAProxy servers such that we could easily lose one and then it wouldn't have a massive effect. But it was very hard to manage because we kept adding more and more machines as we grew. With Cloudflare we were able to just scrap all of that because Cloudflare now sits in front and does all the work for us. Cloudflare helped us to improve the customer satisfaction. It removed the friction with our customer engagement. It's very easy to deploy and it improves the customer experiences big time. Cloudflare is amazing. Cloudflare is such a relief. Cloudflare is very easy to use. It's fast. Cloudflare really plays the first level of defense for us. Cloudflare has given us peace of mind. They've got our backs. Cloudflare has been fantastic. I would definitely recommend Cloudflare. Cloudflare is providing an incredible service to the world right now. Cloudflare has helped save lives through Project FairShot. We will forever be grateful for your participation in getting the vaccine to those who need it most in an elegant, efficient, and ethical manner. Thank you. Thank you.