The Jamstack Book

Beyond static sites with JavaScript, APIs, and markup

Raymond Camden, Brian Rinaldi

• Verlag: Manning
• Jahr: 2022
• ISBN:
  9781638356936
• Thema: Computer Science
• Thema: Content Management Systems

Jamstack = JavaScript, APIs, and Markup. Use established standard technologies to build super-fast static websites without sacrificing rich, dynamic features. In The Jamstack Book, you will learn how to: Use different static site generators to build websites
Deploy Jamstack sites with 11ty, Next.js, Hugo, and Jekyll
Add dynamic capabilities like form processing and eCommerce
Enhance your Jamstack site with serverless capabilities
Integrate a CMS with a Jamstack site Jamstack sites use JavaScript, APIs, and Markup to create fast, dynamic pages without the overhead of heavyweight frameworks. The Jamstack Book is your essential guide to this exciting new web architecture. Written by renowned Jamstack experts Raymond Camden and Brian Rinaldi, it's filled with real-world projects to develop and hone your skills.You'll learn how to lay out and generate a site, set up your own CMS, and add dynamic features like user logins and search functionality. Confusing jargon is demystified. Plus, you'll get the chance to try out different static site generators and find the one that works best for you. Pick up this book today, and you'll discover how the Jamstack answers your need for speed and simplicity. About the technology
JavaScript, APIs, and pre-rendered Markup put the JAM in Jamstack. This modern web architecture delivers the quick load times of static sites along with the dynamic functionality you need for user-friendly interactive features. Built with lightweight standards and tools, Jamstack sites are fast, secure, easy to maintain, and naturally optimized for mobile and SEO. About the book
The Jamstack Book teaches effectively by creating a portfolio of sites, ranging from a simple blog to an eCommerce store. Each new project introduces important skills, including cloud deployment, user logins, and search. You'll get hands-on experience with tools like 11ty, Next.js, and Netlify. As your skills grow, the examples become more sophisticated, including serverless technology, dynamic forms, and an integrated CMS. What's insideUse different static site generators to build websites
Add dynamic capabilities like form processing and eCommerce
Enhance your Jamstack site with serverless capabilities
Integrate a CMS with a Jamstack siteAbout the reader
For web developers and CMS site developers. About the author
Raymond Camden is the author of multiple books on web development and has been blogging and presenting for almost twenty years. Brian Rinaldi has been involved in static site and Jamstack development since the early days. Table of Contents
1 Why Jamstack?
2 Building a basic Jamstack site
3 Building a blog
4 Building a documentation site
5 Building an e-commerce site
6 Deployment
7 Adding dynamic elements
8 Working with serverless computing
9 Adding a content management system
10 Migrating to the Jamstack

1 Why Jamstack?

This chapter covers

• Defining Jamstack as an architecture for web applications rather than a prescriptive stack of technologies
• How Jamstack formed in response to dynamic web page development that had become cumbersome, slow, and insecure
• Benefits of Jamstack, including page speed, security, and cost
• Exploring well-known websites that are built with the Jamstack

As Jamstack has gained popularity in recent years, a common criticism lobbed at it is that it is just a marketing term. The truth is that they are right. As we’ll explore, Jamstack was a term invented to “rebrand” an architecture many developers were already using to build sites because the existing terminology had become misleading. While calling it marketing may be a fair critique, Jamstack is still a way of building sites that has been gaining rapid adoption by web developers.

1.1 What is the Jamstack?

The Jamstack is not a simple thing to define. There is no Jamstack installer. There’s no predefined set of tools you should install that comprise the Jamstack. There’s not even a specific language associated with developing Jamstack apps. (Yes, JavaScript plays a central role, but any number of languages may also be involved, including Ruby, Go, Python, or others.) Ultimately, there are countless combinations of tools and languages that can be combined to create a site that could legitimately be called Jamstack.

What Jamstack is instead is more of an architectural pattern or methodology for creating sites. While there is a lot of ongoing debate about this, these are the key elements as we define them:

• A Jamstack site is primarily built on static assets. Jamstack sites are always deployed as static files. This means that they are not dynamically generated by an application server when the user requests a page; instead, the site files are generated at build time. For a Jamstack site, every user who requests a specific page in their browser will get the same static asset returned. However, this does not mean the content is static. In fact, modern Jamstack sites offer an array of rendering options for the content of pages, including fully static and server-side rendering.
• A Jamstack site is built using a static site generator. The static assets in a Jamstack site are generated using a static site generator (SSG). At a very basic level, a SSG is a tool that takes templates and combines them with content. Content can be stored in files as Markdown, YAML, or JSON files or be pulled from APIs. The content and template combine to dynamically generate the site’s HTML, CSS, and JavaScript assets. This is similar to the process a dynamic web server like PHP might go through on each user request, but, instead, the majority of this process happens at build time before the site is even deployed.
• A Jamstack site leverages APIs. What differentiates a Jamstack site from a simple static site is that, although it is comprised of static assets, it can be very dynamic. The first key ingredient to creating this dynamic functionality is the use of APIs. These APIs can be called by the browser client at run time or even called by the static site generator at build time.
• A Jamstack site uses JavaScript for dynamic functionality. The second key ingredient to making a Jamstack site dynamic is its ability to call APIs and other services asynchronously on the client via JavaScript. JavaScript is what allows the static assets to change dynamically via document object model (DOM) manipulation. Client-side JavaScript powers things like user logins or shopping carts.

Clearly there’s a lot of flexibility in this definition, which, in my opinion, is part of Jamstack’s appeal. There is almost certainly a combination of Jamstack tools and services that meet the needs of your project and your language, tooling, and deployment preferences.

That flexibility has a cost, though. There isn’t a single way to teach someone Jamstack, and the multitude of options can make the learning curve for newcomers a bit steep. Also, there is arguably additional complexity in creating a site that leverages a variety of APIs and services while also dynamically updating content on the client using JavaScript.

So why choose Jamstack? The Jamstack evolved in part to address the problems of a dynamic web that many felt had become slow, costly, and insecure. To better understand the need for the Jamstack, we need to understand how and why it evolved.

1.2 A brief history of Jamstack

By learning why the term Jamstack was created in the first place, we can gain a better understanding about what it is and why it has been rapidly gaining popularity. This is especially true because while Jamstack is a modern architecture that leverages many of the latest trends in technology, in other ways it harkens back to the way we built pages when the web was just invented.

The earliest web pages were just simple HTML deployed to a web server. For example, the first website, as shown in figure 1.1, was just a basic static site. Every person who visited the site received the same assets.

Figure 1.1 The first web site was a static site. It is still available at http://info.cern.ch/hypertext/WWW/TheProject.html.

As the needs of the web evolved, so did the technologies that underpinned it. Web application servers and server-side scripting languages such as PHP and Ruby allowed sites to dynamically generate content. This allowed every user to be served custom assets that were dynamically rendered on the server before they were sent to the individual’s browser. Today this is commonly referred to as server-side rendering (SSR).

Let’s look at how a typical server-side rendered web application worked circa 2008 (why 2008? I’ll explain in a moment):

• The user would request a page from the browser.
• The browser would hit the web application server, which would load the requested page built using some form of scripting language.
• The scripting language would make calls to the database for things like user information, product information, and/or content.
• The data and script would be combined to generate the HTML that was then sent to the user.

This process would be repeated on every page request. It allowed for highly personalized and dynamic content to be served from a single script file, but it came with costs:

• Performance—Each piece of this process entailed small performance costs, from the application server processing the request to the database processing queries, to generating the final HTML. Since this process repeated on each page request for every user, the costs could add up quickly and could be compounded when a web application server or database was under heavy load.
• Security—By nature these applications left a wide surface area open to potential attack. These could include things like vulnerabilities in the web application server to the scripting langu...