Jumpstart Jamstack Development
Close
    • Jumpstart Jamstack Development
    • Jumpstart Jamstack Development
    • Foreword
    • Contributors
    • About the reviewers
    • Preface
    • Who this book is for
    • What this book covers
    • To get the most out of this book
    • Download the example code files
    • Download the color images
    • Conventions used
    • Get in touch
    • Reviews
    • The evolution of the Jamstack
    • HTML
    • Server-side includes
    • The Common Gateway Interface
    • Forms
    • Web page preprocessors
    • Content Management Systems
    • WordPress
    • Ajax
    • JavaScript frameworks
    • The rise of the cloud
    • High-speed access
    • The rise of the Jamstack
    • The Jamstack acronym explained
    • Jamstack advantages
    • Our Jamstack
    • GatsbyJS
    • Sanity.io
    • Netlify
    • Getting started with the Jamstack
    • Installation
    • Prerequisites
    • Summary
    • Technical requirements
    • Account setup
    • Introduction to Sanity.io
    • What is GROQ?
    • Creating a project
    • Introducing Sanity Manage
    • Sanity.io project pages
    • Sanity Studio overview
    • Navigation
    • Summary
    • Technical requirements
    • Modifying the example author
    • Modifying the existing author
    • Creating an additional author
    • Removing and adding articles
    • Removing example articles
    • Creating a new article
    • Modifying the website settings and redeploying the website
    • Setting the website name
    • Redeployment through Netlify
    • Summary
    • Technical requirements
    • Modeling content with schemas
    • Cloning the project
    • Exploring the project's folders
    • Schema relationships
    • A one-to-one relationship
    • A one-to-many relationship
    • Extending, modifying, and deploying the schema
    • The event schema
    • The venue schema
    • The schema file
    • Deploying the schema
    • Summary
    • Technical requirements
    • Why GROQ?
    • Installing Vision
    • GROQ versus SQL
    • Basic queries with GROQ
    • Selecting all events
    • Selecting all upcoming events
    • Selecting all past events
    • Selecting upcoming virtual conference and non-virtual conferences
    • Selecting specific event fields
    • Selecting specific fields from relationships
    • Advanced GROQ
    • Getting events by venues
    • Formatting the response
    • Count result
    • Summary
    • Technical requirements
    • An introduction to GraphQL
    • Deploying the GraphQL API
    • Basic GraphQL syntax
    • GROQ versus GraphQL
    • GraphQL playground basics
    • Query parameters
    • Summary
    • Technical requirements
    • Gatsby, built on React
    • Gatsby basic project structure
    • gatsby-config.js
    • dotenv
    • Key Gatsby files
    • Gatsby folders
    • The gatsby develop command
    • Summary
    • Technical requirements
    • GraphQL in GatsbyJS
    • GraphiQL, a GraphQL navigator
    • Summary
    • Technical Requirements
    • Understanding plugins
    • Node Package Manager
    • Semantic versioning
    • Installing a package from npm
    • Searching, installing, and configuring plugins
    • The Gatsby Plugin Library
    • Searching for a plugin
    • Installing and configuring the gatsby-source-filesystem plugin
    • Installing and configuring the gatsby-transformer-remark plugin
    • Installing and configuring the gatsby-source-drupal plugin
    • Summary
    • Further reading
    • Technical requirements
    • React components
    • Tag convention
    • Understanding the types of components
    • Gatsby page components
    • Gatsby template components
    • Gatsby partial components
    • Summary
    • Technical requirements
    • Introduction to APIs
    • Gatsby – APIs
    • Creating a Netlify form
    • Configuring a token form in Sanity
    • Configuring a Netlify function
    • Summary
    • Technical requirements
    • Alexa skill life cycle
    • Skill interface
    • Skill service
    • Creating the skill
    • Configuring the skill through the skill interface
    • Build
    • Code
    • Test
    • Summary
    • Technical requirements
    • Gatsby.js layout modifications
    • Introducing Tailwind CSS
    • Installing the Tailwind CSS framework
    • Using the Tailwind CSS framework
    • Improving and formatting the event list
    • Preparing for deployment
    • Cleaning up the code
    • Toggling the venue visibility
    • Summary
    • Technical requirements
    • Introduction to Netlify
    • Netlify plugins
    • HTML Minify
    • Advanced configuration through the netlify.toml file
    • Netlify deployment via the command line
    • Azure Static Web Apps deployment
    • Static web app creation
    • Static web app continuous deployment
    • Summary
    • Summary of concepts
    • The Jamstack's future
    • Jamstack, JAMstack, and JAM Stack
    • The Jamstack community resources
    • Contributing to Jamstack projects
    • Contributing to Sanity
    • Contributing to Gatsby
    • Contributing to Netlify
    • Final thoughts
    • Leave a review - let other readers know what you think

History of the Jamstack

Welcome to the Jamstack. This completely new web development paradigm has excited the information technology industry and is becoming steadily more popular, with new companies constantly forming around it. This book is one of the first of a few tutorials available focused on practical and hands-on experience with the Jamstack.

A technology stack represents a specific collection of languages, databases, and operating systems, such as the LAMP stack. The acronym LAMP stands for Linux, an operating system; Apache, a web server; MySQL, a database; and PHP, a programming language. The Jamstack is actually not a stack in this sense, but rather a new methodology and toolset to produce websites and web applications.

In this chapter, we're going to first look at the history of the web, introduce the Jamstack, and discuss its advantages. To understand how the Jamstack evolved into what it is today, we need to look back at the more-than-two-decade history of the World Wide Web. Web design and web development, the two main industries that evolved from the World Wide Web, developed into two very popular and lucrative occupations, but it wasn't always that way.

These are the main topics that we will cover in this chapter:

  • The evolution of the Jamstack
  • The rise of the Jamstack
  • Our Jamstack
  • Getting started with the Jamstack

The evolution of the Jamstack

The evolution of the Jamstack can be easily explained by looking at how the World Wide Web evolved, starting with its most central component, HyperText Markup Language (HTML).

HTML

The very first web pages were simply comprised of text with HTML tags, providing markup instructions with the ability to link pages together. In fact, HTML is often mistaken by the average person as a programming language, but it was, at the most fundamental level, a series of symbols that represented formatting instructions. It still gets included in programming language lists, together with actual programming languages such as C and Java. It is merely a markup language, though, despite having evolved rapidly to now include accessibility and semantic features. This means that it is not much more than markup. In its earliest versions, however, it simply provided general formatting instructions.

For example, we could use an h1 tag to represent the header of a page, which would make the text appear larger, or a bold tag to make the text bold. Each page would consist of text, links, and HTML tags.

The following code snippet provides an example of this:

<html><head><title>My Webpage</title></head><body><h1>Welcome to my webpage.</h1></body><html>

As the number of web pages on websites grew, weekly—or even daily—tasks involved updating up to 50 pages manually. Every time a change was needed in a shared part of a web page (such as the header, footer, or navigation pane), these repeated actions proved to be quite tedious.

Let's investigate some solutions that were devised for this problem.

Server-side includes

One attempt to remedy this repeated manual work was called a server-side include, or SSI. This markup element was created to allow web designers to include pieces of pages (for example, the header) without having to repeat content and markup. Then, when the page was generated, the tag would be replaced with the resultant HTML output.

For example, three links on a web page, Home, About Us, and Contact Us, would have the following markup:

<a href="home.html">Home</a><a href="about_us.html">About Us</a><a href="contact_us.html">Contact Us</a>

This HTML could be placed inside a file called navigation.ssi. The include would be called as follows:

<!--#include virtual="navigation.ssi" -->

After the web server processed this, the result shown on the page would be the same as that shown in the preceding example. Next, another similar approach was used to allow for dynamic content to be produced.

The Common Gateway Interface

The Common Gateway Interface or CGI, allowed programs written in languages such as Perl to be included in a web page, providing added functionality such as a page counter. The actual place in the HTML page that called this code would again be replaced with the resulting HTML output.

A Perl script that counted the number of page visitors was placed into the cgi-bin directory and called as follows:

<p>This page has been visited<!--#exec cgi="/cgi-bin/counter.pl"--> times.</p>

This would produce the following result on the web page:

<p>This page has been visited 5349 times.</p>

The number 5349 was produced by this code and displayed on the page.

Forms

Another important part of the history of web development was forms. Forms allowed a simple web page to transform itself into an actual web application. Web forms replicated the functionality of traditional forms found in desktop applications. Web forms also enabled end users, as opposed to the webmaster, to add content—for example, in forums, submission forms were used.

On the public-facing portion of a website, submissions from these forms added even more content as websites grew quickly in size. Sites soon effectively became software applications, more than just a collection of files with markup. Soon, more than just serving simple pages, web server modules were created to preprocess entire pages as programs.

Web page preprocessors

Another interesting part of the evolution of modern web development was the ability to use whole page preprocessors, such as PHP. In fact, this language, recursively called PHP: Hypertext Preprocessor, explains exactly what it does. These files had a different file extension, and the web server (such as Apache) could process the entire page as an actual program and output the result as HTML tags and content.

Next, let's move into the modern era: Content Management Systems (CMS).

Content Management Systems

Soon, databases such as MySQL were included in affordable web hosting plans so that webmasters could easily use them. Database tables could be queried, and the results would enrich and add meaning to many dynamically generated pages. This laid the groundwork for the first CMS.

By allowing website administrators and webmasters, as they were historically called, to manage content in databases, dashboards or control panels were created. A web-based software application entirely separate from the actual website, these administration tools allowed website content to be easily created, edited, and deleted from the website itself.

Again, this caused websites to grow both in size and complexity very rapidly.

WordPress

WordPress quickly rose as the most widely used CMS. Extending the functionality of WordPress, a collection of plugins was developed whereby anybody could develop and install a plugin. This meant that at any one time, a WordPress website could potentially have hundreds of different plugins installed all at the same time.

Most of these were maintained by ambitious volunteers, and new functionality was quickly added. This phenomenon led to rapid release cycles and many different versions of each plugin in use at the same time.

Ajax

Another major innovation was the creation of Ajax, or Asynchronous JavaScript and XML. Ajax allowed a page to fetch information from a remote source and then, with the result, update that page's content, layout, or style without requiring the page to reload. This instant update made websites that still required pages to reload seem cumbersome and slow. Websites again slowly evolved to be one step closer to becoming software applications, similar to desktop applications or single-page applications.

JavaScript frameworks

As the complexity of this dynamic page manipulation grew, JavaScript frameworks were born. These helped to reduce development time and enforce best practices. They also provided JavaScript code that could be functional in as many versions of as many browsers as possible. There are still as many as 100 variants of browsers such as Internet Explorer, Firefox, Opera, and Google Chrome running on desktop computers, tablets, and mobile devices.

The rise of the cloud

As the web grew in popularity, web hosting costs decreased. The availability of very low-cost web hosting increased rapidly as many companies entered into the market. Website hosting companies and cloud providers saw an opportunity in this, putting the ability to create a website within reach of almost anybody with very little technical skill, at a very low cost.

As history would show, as with the automobile, sometimes the best inventions also foster many problems. Just as the invention and evolution of the automobile has led to crashes, traffic jams, and safety and security issues—so did websites! Since the majority of websites on the internet were created by amateurs and hosted on servers that were not adequately secured, vulnerabilities on the server were soon discovered and then taken advantage of.

Using a combination of outdated or insecure WordPress plugins, insecure JavaScript, and general misconfiguration of web servers, compromised websites could then be used to send spam emails through utilization of the Simple Mail Transfer Protocol (SMTP). These exploiters inserted email addresses and email contents into database tables and then, in an automated manner, sent thousands of emails per hour, hopefully convincing people to spend money. Keeping a server secure by limiting which tools on the server could be accessed by a user, locking down directories, not allowing repeated login attempts, and other techniques were used to reduce security risk.

However, the overhead of having to make sure that all of a website's plugins were up to date soon became overwhelming. Situations such as version 3.12.26 of a particular plugin not working with version 6.8.14 of another became commonplace. The web slowly became the Wild West!

High-speed access

As high-speed internet became pervasive, connection speeds increased to approach 50-100 megabits per second (Mbps) on home computers, through digital subscriber line (DSL) and cable internet. Web designers took more liberty regarding the amount of information, images, media files, JavaScript, and anything else that was to be placed on a single web page. This led to a slowing down of what were previously quick-loading websites.

Also, the pages required multiple steps to actually be dynamically generated. Live-running code and database queries needed to be interpreted on each and every request. Page time slowed down because of all of the steps needed to deliver a single web page. As history has shown, a new solution will always arise to address new problems. This solution is called the Jamstack.

Let's begin to dissect what it is.

The rise of the Jamstack

The Jamstack represents all that was good about the initial days of web design, together with all of the things that are good about modern web development. Static site generation, as it's sometimes referred to, means simply generating a website comprised of pages that are literally files and nothing more. There is no backend preprocessor and no database, and all of the server complexity is abstracted away.

The Jamstack acronym explained

The Jamstack acronym stands for JavaScript, APIs, and Markup. Since a static site page cannot be produced by any real-time preprocessing, all dynamic aspects of the page must be achieved through JavaScript, which will perform all page interactions.

JavaScript will communicate with external systems, such as search engines, using application programming interfaces (APIs). The use of APIs is a modern way of either leveraging pre-built external Software-as-a-Service (SAAS), such as Algolia's search API, or using another software application that would previously exist on the same server as the static site. Limiting communication to APIs allows each component of a larger system to remain independent and reusable.

Finally, Markup represents the page itself. As mentioned, HTML is a language that it used to create web pages. Sometimes, Markdown is incorrectly used in the place of Markup. Markdown is actually one of the notations used to produce markup; however, there are many different ways to produce markup.

Jamstack advantages

Now, let's learn about the advantages of the Jamstack.

Speed

As mentioned before, one of the advantages of static pages is that each page is actually a file on the filesystem. As in the early days of web design, each file is loaded through a web server. The only bottleneck is the speed of accessing the file, reading it, and then sending its contents through the web server.

A Content Delivery Network (CDN) is a network of many servers placed all over the world. This means that the pages will be optimally served from the nearest server to the website user, reducing network latency. This represents an overall faster and better experience for the end user.

All of the Cascading Style Sheets (CSS) and JavaScript will usually be minified or compressed in a way that removes unnecessary characters, spaces, tabs, line breaks, and other non-essential items. The fewest number of characters are used and combined together in one or more files as a way of reducing the number of files involved.

Non-minified JavaScript looks like this:

<javascript>function multiplyTwoNumbers(number1, number2){return number1 * number2;}var result = multiplyTwoNumbers(2,3);</javascript>
Minified JavaScript looks like this:
<javascript>function a(b,c){return b*c;}var d=a(2,3);</javascript>

Less error-prone

Most Jamstack systems have a build process that checks all of the HTML, JavaScript, and CSS for correctness during the process that builds the pages, so a serious coding error will cause the build to fail, not allowing the error to actually make it into production.

Security

Using the safe HyperText Transfer Protocol Secure (HTTPS) instead of the older HyperText Transfer Protocol (HTTP) means that all information transmitted will be secure, as it is encrypted from end to end.

Also, since static pages are served through serverless hosting services, there is no chance that any backend systems or databases could be compromised. No longer is there a need to spend valuable time keeping the server, libraries, login access, and mail services secure and always on the latest version, or even worrying about conflicts between the various versions.

Developer experience

Developing in the Jamstack means using popular and modern programming languages, such as JavaScript, TypeScript, and ECMAScript 6 (ES6) variants. Jamstack developers may also take advantage of modern query languages such as GraphQL, and libraries and frameworks such as ReactJS and VueJS. They may also use static site generators such as Hugo and GatsbyJS.

Our Jamstack

As should be clear by now, the Jamstack is not a stack, but rather a web development paradigm. Any combination of the various components of the Jamstack ecosystem may be used. For this book, we will use three of the most popular software applications and services to produce a Jamstack website: GatsbyJS, Sanity.io, and Netlify. We will also provide several examples, using other Jamstack tools for comparison.

GatsbyJS

One of the most popular parts of the Jamstack that is actually a static site generator is GatsbyJS.

GatsbyJS (referred to as Gatsby) is open source and uses the React JavaScript library to compile and build static pages from various sources. These sources may be as simple as a filesystem; a collection of Markdown files; a traditional CMS such as WordPress or Drupal; or a headless CMS such as Contentful or Sanity.

Sanity.io

Since the Jamstack way of doing web development eschews a single, monolithic CMS, the actual content that a website needs is separate from the tools that will format it and deliver it.

Sanity.io (referred to as Sanity) is a platform for structured content. There is an open source CMS called Sanity Studio, which enables content producers such as writers, editors, and photographers to easily create rich content that is flexible and modular, without the need to understand programming and markup languages.

Netlify

The actual hosting of the website will be done on a serverless system.

Netlify is a service that enables a developer to enjoy fully automated compilation and deployment onto Netlify's CDN, pushing content out quickly and safely to servers throughout the world.

Getting started with the Jamstack

Now that we have learned about the history of the Jamstack and its advantages, we will next look at the tools necessary to use the Jamstack in the context of this book.

Installation

Installing all of the pieces of a Jamstack development environment and configuring everything to work properly will be daunting for developers who are new to the technology, so the best approach is to refer to each of the components' websites for up-to-date installation and configuration documentation.

This book has an accompanying GitHub repository with all of the code necessary to perform all of the examples. Therefore, the first tool that needs to be installed will be the Git version control system. Users who are new to Git will find a vast amount of information, cheat sheets, and help forums for its usage, but most of the basic operations are performed with only four or five commands. Many code editors, such as WebStorm, have the commands built into the user interface.

To ensure that the installation process is up to date, the README.md file in the provided repository will provide installation instructions and links to each project's current documentation.

Prerequisites

Several web development tools are necessary to work with the examples in this book, and these are listed here:

  • Terminal
  • Node.js and node package manager (npm)
  • Git
  • An Integrated Development Environment (IDE) or text editor

A Terminal environment will be needed to execute commands. Which Terminal application should be used will vary depending on the operating system used.

Node.js allows JavaScript to be run in the Terminal, not only in the browser.

npm is necessary for the installation of both Sanity and Gatsby. This allows many packages that are groups of JavaScript functionality to be installed.

The Git command-line version control system is essential for the installation of Gatsby and also to download the examples in this book.

Finally, an IDE that provides code syntax highlighting and linting, which continually analyzes the code for correctness, is needed. If this is not possible, a text editor is needed to modify the source code files. As of this writing, Visual Studio Code and WebStorm are two popular IDE choices.

Optional tools

Optionally, Yarn may be used for the examples in this book. Yarn is an npm-compatible replacement for npm and while it is suggested, it is not required.

Summary

In this chapter, we learned about how the World Wide Web grew from simple pages with markup and links, to become massively slow and insecure web applications. We learned how the Jamstack combines various aspects of the past and present to form a truly modern, decoupled, and enjoyable paradigm to work with for web developers and web designers wishing to learn more.

In the next chapter, we'll begin our journey into the construction of a real, working Jamstack application. We'll become familiar with Sanity and a web-based tool to quickly create a sample application, using one of several templates.

We will introduce Sanity and its features and show how to modify its schemas. We will show how to use Sanity to design and build the structured content needed to create a website with news and events.

Community Questions