 If you're a web developer, chances are you've heard the term Jamstack. Jamstack isn't a solution to prevent clogged printers, something to eat on toast or even a way to make music. Instead, it's an architecture for designing super fast web applications that easily scale. In this video, we'll cover the Jamstack architecture, the numerous benefits of the Jamstack approach, and tools you can use to implement a Jamstack web app. You'll walk away with a clear understanding of Jamstack, the resources to quickly build your own web app at ludicrous speed. Let's get started. I started building web apps in the late 90s with classic active server pages and SQL server. I built an internet app for a large manufacturing site so that they could share documents, training, and safety information with their employees. Admins could log in and update content, and I didn't realize it at the time, but I ended up creating a content management system, a CMS. I found it amusing that mainframe programmers looked at the internet and browsers as the new dumb terminal. At the time, I thought they were looking at the internet as a step back instead of a step forward. Now that I'm older, I see that it was just them recognizing some familiar patterns and mapping new information in ways that they could better understand it. 2000 came around and I jumped on the .com bandwagon. In my next job, I built a new CMS. And then .net came along. What was the first thing I built? You guessed it. Another CMS. And then just CMSs for days. Every app was a nail and my hammer was the CMS. I got tired of building all those one-off CMS apps. So just as many developers have done in their career at one time or another, I decided it was time for us to build a framework. All we need is a good framework. A framework will solve all our problems and help us to go faster. So instead of rapidly developing and adding features to one app at a time, I was able to grind several projects to a halt while each waited for my framework to solve every problem for all time. I got lucky. I pulled it off and I built a pretty awesome application framework and CMS. It had features I was really proud of, but it was a Frankenstein monster that was awful to configure a beast to maintain and deploy. And it's scary to think that there are still some apps out there using it as far as I know. This was over-engineering at its finest. Hello, my name is David and I'm in recovery for building content management systems and unnecessary frameworks. Let's walk through an example of a typical web application request. You have a client like a desktop or mobile browser and it wants to access a page on your website. That request goes to your server and this web server could be any platform running any language such as Java, PHP, ASP.net, Node.js, or a popular CMS like WordPress or Joomla. The web server figures out what page to render, fetches whatever data it needs to render that view, and the database responds with some data. Of course, in the real world, it's usually not that simple. Have you ever opened up a query inspection tool like SQL Profiler and witnessed just how many database calls an application makes to generate a single page of content? It can be absolutely horrifying. So the web server gathers all the data it needs. It combines that data with a template system of some kind and returns HTML to the client. We'll call this pattern the web request walk of shame. Okay, well, that's great. We've solved our problem. Oh wait, what's this? Sir, the web requests are coming in too fast. There's too many of them. We can't keep up. Our radar has been jammed. Oh great. Now we need to scale. What do we do? One measure of a speed is request per second. Let's say for the sake of simplicity that one page in our app can handle 100 requests per second. Sounds reasonable? What if we need more? Theoretically, we could add another server and get 200 requests per second. But what does that really mean? Well, things start to get a little more complicated. We'll need to add a load balancer. We'll need to terminate our SSL certificates at the balancer. We need to deploy code to multiple places instead of one. We'll have to take one server out of the load balancer, update it, switch servers, update the next server, add it back to the load balancer. And then what if after we add more servers that we discover the database has become the bottleneck? Good grief. Well, we could add some caching. Wow, we went from 200 requests per second to 2,000 requests per second. That's amazing. Some people are reporting that they're seeing inconsistent results. How do we invalidate the cache? It's not as simple as we first thought. And we keep having weird performance issues. I guess we'll just add some more cache over here. It's okay. We can handle this. We've got it under control. We can stop anytime we want. Oh, no. What have we done? And we haven't even talked about security. Building a dynamic server-based application, you have to keep up with all the latest attacks. Server-based apps have huge attack surface area. All the endpoints for managing and administering your application are out there for all the hackers to hack. And if you use a CMS, the plug-ins can be a big risk. All your admin accounts, all your content, or your site could be brought down by a denial-of-service attack. Plus, attacks are continuously becoming more sophisticated and are ever-evolving. Using a popular framework or CMS might mean you get better support and fixes for known exploits. But it could also put you at more risk because more people, more hackers are targeting popular frameworks. I used to run a shared hosting service where I bought and managed servers. I've seen firsthand some of the crazy things that can happen to compromise a website or even an entire server. The expectations of visitors and application users these days aren't too demanding. They only want your app to be beautiful, interactive, dynamic, real-time, with messaging and video, with seamless transitions between pages, and of course, mobile-first. Seems reasonable, right? And there are so many ways of measuring performance. There's time to first bite, time to first paint, time to first meaningful paint, page load, time to interact, time to last bite, bounce rate, request per second, throughput, error rate, conversions from visitor to lead to customer. Wow. What we need are more acronyms in tech, don't you think? Why do we have all these ways to measure performance? Because seconds count. A single second more could mean visitors give up and you lose potential customers. There are numerous studies on the effects of performance on signups and conversions and revenue. For example, Pinterest increased search engine traffic and signups by 15% when they reduced wait times by 40%. Cook increased conversions by 7% when they reduced average page load time by just 850 milliseconds. The BBC saw that they lost an additional 10% of users for every additional second their site took to load. And then DoubleClick found that 53% of mobile visitors abandoned their site if a page took longer than 3 seconds to load. Performance matters. In the last five years we've seen some amazing emerging trends in web technology. More than ever before, it's possible to build rich, powerful, responsive, dynamic web apps without ever touching a single server. No traditional hosting, no servers to provision, no virtual machines, no servers to maintain. We don't even have to use Docker or containers or Kubernetes. We can do something like open up a terminal and type get push. And when we press enter, magic. And just like that, you have an industry leading, fast, scalable, globally distributed, secure, highly available, agile, lean, fault tolerant, flexible, decoupled, world-class, interactive, personalized, dynamic, mobile-first, progressive, disruptive, real-time, seamlessly integrated digital transformation with analytics, AI and machine learning. Did I miss any buzzwords? What a time to be alive. Jamstack is nothing new. Netlify, a popular content delivery network, a CDN, coined the name Jamstack. But Jamstack is not a particular technology or vendor. In some ways you may already have parts of the Jamstack in your stack. Jamstack is a label like Web 2.0. Remember Web 2.0 and the rise of Ajax? Jamstack is a set of emerging trends for building modern web applications. Those trends include things like get workflow, continuous integration, continuous deployment, static site generators, front-end frameworks, APIs, which could be best-of-breed third-party APIs or serverless or GraphQL, and, of course, content delivery networks, CDNs. The Jam in Jamstack stands for JavaScript, APIs, and Markup. Although JavaScript is the primary language of the browser for making the front-end more dynamic, you can choose whatever language you wish for things like templating, building your assets, automating your deployments, creating your back-end APIs, and so forth. In the web request walk of shame, caching is pretty awesome when it works. It can short-circuit a request and return the exact results. A cache can be introduced at lots of different levels from the database and up. The goal of a cache is to reduce compute cycles. Less work for the database or the server means less latency, means fewer network calls. Do you know what the best cache is? A static file. The absolute fastest request a web server can serve is a request for a static file. You can read a file from the disk and you send it. There's no calls to other APIs, no databases to query, no templates to execute. Anything more than a static file requires CPU cycles to execute code and generate a response. A static file wins over code every time. Part of Jamstack, the number one goal is to maximize pre-built markup and assets. How can we serve more files? All the other technologies and practices considered to be part of the Jamstack architecture come down to how can we make the workflow better, faster, more automated? How can we maximize the amount of the app that we can make static? And then pushing those static assets to the edge, closer to your visitors and your customers. The edge that I'm talking about are the CDNs. Content delivery networks are extremely powerful. CDNs have become cheaper and in some cases completely free. Smarter with regards to atomic deployments and cache invalidation. They reduce the latency, being physically closer to your visitors. And CDNs are the experts when it comes to scaling to meet demands in traffic as well as restraining the hackers. There's an unfortunate negative connotation to the word static. In the modern world of web development, static is anything but static. Static is pre-compiled HTML, CSS, JavaScript, images and any other content that can be delivered without using any compute resource. Ideally a CDN. Once it reaches the client, the app can be as personalized and dynamic as anything you can imagine. The shift is in thinking about moving the runtime from the web server to the browser or to the client. The design of a Jamstack application is kind of like a native mobile application. In a native app, everything is pre-built. It includes most of the assets that are needed to run the application. It connects to powerful APIs, which could be yours or third-party APIs. It loads super fast and it's interactive. Remember our web request, Walk of Shame? Well now I give you the Jamstack request to Glory. The client requests a web page. That request goes to the CDN. And the CDN returns a response. The CDN just sits there serving files like a psychopath. There's nothing faster. You have achieved ludicrous speed. So how do we get there? In light of the information I've given you so far, what if I told you that you need to stop writing silly server-side code in whatever language that you use and instead turn your focus on building static assets? No, no. That sounds disgusting, right? I get it. This was my reaction too. I'm not going to give up my favorite platform, my favorite language, my favorite frameworks. Well, I submit to you that there's no code faster than no code. Eh? Think about it. And there's no code that's more secure than no code. Am I right? Deploying static assets, a huge portion of your application's attack surface area just simply disappears. Well, all is not lost. You can still use your favorite platforms and languages just perhaps in new and more focused ways. A typical Jamstack architecture and workflow might look like the following. You may have a Git repository where you have your front-end UI, some content and templates used for rendering your assets. You might have what's called a headless CMS designed for Jamstack where you maintain your content. I'll talk more about this later. And you may have one or more third-party APIs or APIs that you've created to add more features to your app. When you make a change to any of these, a webhook or some other type of event triggers your build process to build your application. Your build process kicks off taking all the markup and templates in your repository to start compiling all the assets for your application. Your build process might reach out to your CMS, your APIs, databases, and so forth for additional content and data to compile into the rendered content. As much as possible, the final output will be like a snapshot of everything that makes up your application. Your pre-compiled assets are then deployed, ideally to a CDN, and when a web page is requested, the static content is delivered and rendered as quickly as technically possible. Your application might then use JavaScript to progressively enhance the application experience using your APIs or third-party APIs. One of the many benefits of using a CDN is atomic deployments. This means each new build of your application is deployed throughout the CDN and then there's a flipping of the switch, so to speak, that happens all at once, like a transaction. This also means if you need to, rolling back to a previous version of your application becomes rather trivial and you can do that with confidence. Static site generators have been dismissed as being only good for documentation, but today there are amazing generators for every language and platform. If your front-end team loves React, they might love Gatsby or Next.js. If view is your thing, try Nuxt. If you want the fastest builds possible, try something like Hugo. If you want something really simple that supports lots of different template engines, try Eleventy. You can even use good old Jekyll. In recent years, we've seen an explosion of great API platforms and the market will continue to grow. You can progressively add features to your Jamstack application from the best APIs available, such as Algolia for search, Shopify and Stripe for e-commerce and payments, Okta for authentication, Twilio for messaging. Fauna is an exciting modern scalable database with native GraphQL support. Why would you dare build a system for sending text messages or emails when you can leverage an expert like Twilio and SendGrid? Why build a payment system when you could use something like Stripe? Why build authentication when you could use something like Okta? Okta provides login, authentication, password reset, user profile management, identity, multi-factor authentication, securing your content, adding personalization. It supports standards like OAuth and OpenID Connect to make it easier for users to integrate with other services. Why would you not use Okta? These are the experts. They are far more vested in being the very best at what they do. More so than you could ever be with your own implementation. Plus, your attack surface area is minimized. Third-party APIs carry the burden of securing and scaling their own infrastructure. They know a thing or two because they've seen a thing or two. If you need to build your own APIs, now would be the perfect time to consider using functions as a service, such as AWS Lambda's Azure Functions, Google, or Netlify functions. Functions as a service automatically scale to meet whatever demand and you pay for only what you use, much like a CDN. Taking the JAMstack approach to decouple your front-end JavaScript APIs, markup, and create a predictable and confidence-building continuous integration and deployment process, leveraging best-of-breed third-party APIs, your dev teams are free to focus intensely on building features instead of maintaining a monolithic app, or CMS, managing infrastructure, fighting complexity, and a multitude of challenges that arise from building server-side applications. There are a lot of choices to be made on designing a JAMstack architecture that fits your needs, but the overall architecture is incredibly liberating. Back-end developers can focus on APIs and services. Front-end developers can focus on the design and experience. How much time and effort do web teams spend building and managing infrastructure? Deployments, database migrations, monitoring, provisioning servers and networks, load balancers, caching, copying files around like with FTP, managing secrets, config files, keeping environments updated, dev staging and production, backups, logging, monitoring. How much time do you spend on infrastructure versus building real features that bring value to your customers? Now, not everyone who contributes to an application are developers. You may have content creators, technical writers, marketing folks, and other contributors who are more comfortable using the content management system. Well, a whole new market of headless CMS tools has emerged that fits perfectly with JAMstack. These content tools are decoupled from the presentation of that content and largely fall under two categories. There are Git-based headless CMSs such as Netlify, Forestry, and Tina CMS. These typically generate markdown and transparently commit changes to your Git repository, often the same repository where the application lives. And then there are API-based headless CMSs. And these are applications like Contentful, Sanity, or Ghost. During a build, the build tools fetch all the content from the CMS API and use it to generate all the markup. Whether you use a Git or API-based CMS, any update created by the CMS will trigger your build process for the appropriate environment, such as staging or production based on your workflow. So how do we get started with JAMstack? Well, here's an overused quote to help you get motivated. There are lots of resources that I've got listed on a repository about JAMstack. I've included some Getting Started tutorials covering some specific technologies. One of the first steps is to choose a static site generator. Staticgen.com can help with that, which is also in my resources. Most static site generators have great Getting Started tutorials, including how to easily deploy to a CDN. If you need to, you might introduce a headless CMS. HeadlessCMS.org can help with that as well. Again, the link is also included in my list of resources. Maybe you're like me. When you first heard me talk about static site generators and deploying static files, you were like, ah, that sounds terrible. You can't get rid of server-side code. Well, I hope this video has gotten your wheels turning. Maybe if you really think about it, you might realize that, hey, wait, you know, this JAMstack idea just might work. One last thing. I believe those of us in technology have an incredible opportunity to impact our workplaces, our families, our community, and the entire world in positive and meaningful ways. I hope you take what I've given along with other things that you're learning and you go out there and you be awesome. Until next time, thank you and have a great day.