Jumpstart Jamstack Development
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:

Code snippet

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

Code snippet

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

Code snippet

<!--#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:

Code snippet

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

This would produce the following result on the web page:

Code snippet

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

Code snippet

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

Code snippet

<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