Jamstack takes advantage of existing technologies – which we'll discuss in a minute. The result is better performance, improved security, and easier scalability for web applications.

In this article, you'll learn what Jamstack means and the benefits of using this approach in your projects.

What is the Jamstack?

Jamstack is a web development architecture. Matt Biilmann, the CEO of Netlify, popularized it with his presentation at Smashing Conference 2016.

Jamstack is an acronym for Javascript, APIs, and Markup, and is a technology stack you use to build your apps.

This is like the MERN stack (MongoDB, ExpressJS, ReactJS and NodeJS) and the MEAN stack (MongoDB, ExpressJS, Angular and NodeJS) – just with different tools.

Now let's discuss the various components of a Jamstack web application:

Javascript

Javascript is the core programming language of the web. It has been around for decades and you can use it both on the client side and the backend with NodeJS.

Javascript is the programming language you use for handling the client side of your Jamstack applications.

APIs

API is an acronym for Application Programming Interface. It's an interface which helps two or more computer programs communicate with each other.

In Jamstack apps, you use APIs to communicate with your backend.

Markup

Markup refers to standard text-encoding systems consisting of a set of symbols inserted into a text document. Examples of markup languages are HTML, XML, and templating languages such as JSX.

In the Jamstack, markup refers to the content of a Jamstack application. Note that we use markup here in its broader sense. It doesn't refer to text content only but also to the assets of the web application, such as images.

Important Features of Jamstack Apps

To consider an application a Jamstack app, it should meet the following conditions:

Distributed Architecture

This refers to the decoupling of the client side from the backend. The client side handles the presentation of the user interface, and the backend handles business logic and data.

Communication between the frontend and backend happens via a dedicated API. This means that a change or upgrade in one will not affect the other. This results in easier maintenance of the entire web application.

Static Sites

It is important for Jamstack applications to serve static web pages and not dynamic ones.

Traditional web applications are dynamic sites. This means that when you request a page, the backend will have to reach a database to retrieve the data. The data is then used to generate HTML files, and then sent back to the client.

The disadvantage of dynamic sites is how long it takes to complete these steps.

For static sites, the pages are already pre-rendered at build time. So every time you request a page, you get the pre-rendered page.

This eliminates the time that dynamic sites spend in obtaining data, generating HTML files, and sending it back to the client. You can serve your static sites from a content delivery network (CDN). This will lead to improved speed and reduced costs.

Examples of static site generators that you can use for your Jamstack web applications include:

• NextJS

• Gatsby

• Hugo

• Jekyll

• Nuxt

Why Should You Use the Jamstack for your Web Applications?

Let's now discuss some of the reasons the Jamstack web architecture has become so popular in recent times and why you should consider adopting it:

Jamstack Apps Are Scalable

You can serve most Jamstack applications from a CDN. This allows for the speedy transfer of assets needed for loading web pages.

As a result of the distributed nature of CDNs, your web application will also be able to handle more traffic at a reduced cost.

Jamstack Apps Are Easy to Maintain

Jamstack applications are easier to maintain since their client side is decoupled from their backends.

This means that you can maintain one part without requiring major modifications to the other.

Jamstack Apps Load Faster

As stated earlier, serving your site from a CDN increases the speed with which it loads.

Also, in Jamstack applications, web pages are prebuilt, saving time that would normally be spent retrieving and generating HTML files every time you make a request.

Jamstack Apps Are Cheaper

Since Jamstack applications are easier to maintain and deploy, they are cheaper compared to their traditional counterparts.

Jamstack Apps Are More Secure

Since you do not have to constantly maintain a server in Jamstack applications and the pages are constructed on read-only files (that is, the pages are static), you can worry less about the security of your applications.

Conclusion

Despite the fact that more and more projects are being built using the Jamstack architecture, we're still in the relatively early stages of its adoption.

I believe that more large and small businesses will adopt it in the near future in place of costly monolithic architectures.

One of the most difficult things about getting started in a new career as a developer is figuring out exactly what you should be learning – and then translating that into an effective plan.

There are so many resources out there for learning, so lack of information is not the problem.

The problem is two-fold:

First, it's hard to gather all this information and turn it into a cohesive plan for systematically learning what you want to learn.

Second, it's hard to figure out how to take all these resources and actually learn from them instead of just being stuck in tutorial hell forever.

The struggle is that we get sucked into the step-by-step nature of tutorials and courses and it can be hard to break out of that and do our own thing without having plan to follow.

This guide is meant to help you learn how to put together your own learning plan so you can utilize tutorials and courses while still being able to break out of the set path and begin to forge your own.

It is impossible to genuinely learn to code by just following tutorials and courses over and over again.

At some point you have to step out of the comfort zone they provide and do something on your own.

My hope is that this guide will serve as a transition aid by guiding you towards creating your own learning path instead of telling you exactly what to do.

The Psychological Trap of Step-by-Step Paths

Before we get into the practical methods, we need to talk about why people get stuck in tutorial hell, and how to get out of it.

For most people, the process goes something like this:

You go through tutorials, feeling great. You are breezing through the tutorial, building something from scratch.

Maybe you run into a few small bugs, but nothing you can't work through really quickly.

You go through a few of these, building some small projects along the way.

Then you go to start building something on your own and immediately hit a wall.

You can barely get the project started before you feel like you forgot everything you just learned.

You will feel like you are starting from zero. Like everything you just spent time learning went out the window.

You feel like you didn't learn, so you find more tutorials thinking you need them to learn more before you build something on your own.

And the cycle continues.

In reality you stopped struggling too soon.

The learning doesn't happen only in the tutorials. The learning happens in that moment when most people give up and go back to the tutorials.

That struggle. That feeling like you didn't actually know anything. That's the first step of the learning process.

Don't run from it. Lean into it.

It's a lot harder to do. It's comfortable and easy to slide back into the tutorials because completing them feels good. It makes you feel like you are learning.

But it's a dangerous trap to fall into because the real learning happens as soon as you stop being comfortable and start struggling to build something on your own.

So before we get into the practical steps of designing your own learning plan, please understand this and be ready for it.

There is no shortcut, no easy step-by-step solution. You just need to accept that you are going to struggle and be confused and not know what you are doing.

That is part of the process.

That is where the real learning is taking place.

Embrace it and push through it. The rewarding feeling of having built something from scratch that doesn't exist anywhere else is worth it.

And it's what will stand out to potential employers and clients when you're trying to find work as a professional developer.

How to Decide What to Learn

I like examples and seeing specific implementations of concepts. So in this guide, I'll talk about a concept and then give an example of me going through the process of designing a learning plan for a tech stack I've been interested in for a while: Blitz.js.

In order to decide what you want to learn, you can take a few different criteria into account.

These will vary depending on where you are in your career.

If you are just getting started, I recommend choosing a stack with high potential for employability.

Right now I would recommend React for that.

If you are already familiar with React I would go for learning some Web3 and blockchain.

I'm 7 years into my career and am to the point where my main interest is exploring different emerging stacks that can make my job more efficient. For me that means I am interested in Blitz.js.

I love the idea of having a stack that has the same philosophy as Rails but is built on top of React and Next.js.

You may just be getting started and so you are primarily interested in learning how to build things with React so you can get your first job.

This will vary for each person, but the building blocks of that learning plan design will be the same.

Get Some Initial Exposure to the Tech Stack

The first step in learning any new stack is to simply be exposed to the basics of how it works. The best place to start with this is the official getting started tutorial provided by the stack.

Most stacks will have something like the getting started tutorial for Blitz or React.

But if they don't, do a Google search for a beginner's tutorial for your stack.

After you go through the official tutorial glance through the docs. Don't try to read the docs straight through, just browse and glance to get a high-level overview.

Going through the tutorial will have the added benefit of exposing you to some of the ecosystem of your stack.

Almost everything you use will need at least some sort of other tool to work with.

Going through the tutorial and docs will help you be exposed to those initially, which will help in the next step.

Research the Supporting Components

Now we have our initial exposure done. We are familiar with the basic concepts of the framework and at a very high level know how it works technologically.

The next step is to research the different supporting components we might want to use in building out a complete project.

So in looking at Blitz, I noticed that they have recipes for adding certain functionality to Blitz apps.

For example, they have a recipe for Tailwind CSS, which is a UI system I've used before but would like to be more proficient at.

So I'm going to add that to a list of supporting components.

Don't worry about learning it yet, just keep a list of other supporting tech you want to look into.

I'm also going to add Prisma and Render to that list, since Prisma is the database system that Blitz uses and Render is one of the recommended deployment tools.

That's all I'm going to put on my supporting components list for now, but this is an unusually short list because Blitz is designed to be an all-in-one framework.

If you are learning something more foundational, like React, you could have a potentially never-ending list of supporting components.

For now, just keep a running list of different tech you would like to learn more about and categorize it.

For example, if you chose React, you might want to learn Chakra UI, Gatsby, and Strapi CMS in order to build JAMstack sites. Those would be good things to add to a list of supporting components.

Remember, we aren't diving into these yet, as that would be too overwhelming. We're just making a list to research over time.

Build a Complete Project

Now it's time to find a course or tutorial that builds a complete project from scratch using your chosen technology.

This is to get introduced to how everything fits together and start understanding how the different components you have been researching all work to make something valuable.

Try to find something that utilizes some or all of the components you have been finding.

Don't worry if you can't find one that uses them all, that's fine. We really just want to find a source of learning that will allow us to see how this stack looks when building a complete project.

Google is your friend here, as are any groups or social media sites you are a part of.
I searched 'blitz complete project tutorial' on Google and found a few that look promising.

If you chose React as your stack, I highly recommend the courses from Wes Bos and UI.dev. They both focus on creating full projects and will be great for the kind of learning we're talking about here.

Build Something from Scratch

This part is important. After that complete tutorial, stop. Don't do any more tutorials or courses until you build something from scratch.

Now we get into the hard part, but the part where the real learning takes place.

Take everything you have learned and apply it to building something on your own.

Use the resources as references, but only in the context of building your own thing.

Remember the trap we were talking about earlier. Don't fall into it.

Keep pushing forward through the struggle and work on your debugging and research skills.

Use the familiarity with the different tools you have been researching to slowly piece together a project from scratch.

Make it complete. Add a UI framework so the design looks relatively nice. Add some CI/CD and automated Git-based deployment. Make it usable.

If there are some tools you wish the tutorial/course you found had used, or even some you are interested in learning more about, use those instead.

Make your project different from the course so you can learn how to piece things together own your own.

Write some tests, add some CI/CD workflow, and get it deployed.

For example, Wes Bos has a Master Gatsby course that utilizes Sanity CMS and custom scoped CSS.

Maybe you are interested in building JAMstack sites so you decided to follow that course.

After that course you might try building your own JAMstack site using Tailwind and Strapi instead.

The point is to build something unique and on your own, referencing the content you have been reviewing up until this point as you need it.

How do you come up with ideas for things to build? Try to keep it simple and solve a very small problem you are specifically facing.

If you don't have a personal site, you could learn the JAMstack to build it.

Maybe one of your friends or family has a small hobby or business they've been wanting a website for, there's another great use case for JAMstack.

Maybe you've been struggling to make a certain change in your life because of a lack of tools, so you can build a tool to help solve it.

One of my first personal projects was an app I made called TinyThought. It was a simple Laravel app that helped me journal one sentence per day so I could build the habit.

To learn Blitz I'm thinking I might do something similar to track my strength training progress.

I'm implementing Tiny Habits methodology in order to be consistent with doing pushups, squats, and chin-ups.

So I might create a simple tracking app that allows me to keep track of which days I completed the habit and how many of each exercise I did.

Write About It

Then write up how you built it.

The writing is important.

Writing will solidify your learning and help you get clear on your process more than anything else.

To really solidify learning something, teach it to someone else.

So as you are going through the process of building your custom project, write down everything you are learning, challenges you are facing, and your process for building.

You can create a series or one long, in-depth post and publish it to DEV.to, freeCodeCamp, or your own blog for other people to learn from.

If you prefer video, you can make some videos and put them up on YouTube. The ultimate form of the content doesn't matter, as long as you are teaching the process while making it as clear as possible.

Teaching other people is by far the best way to solidify your own learning and make sure you actually understand what you are doing.

Rinse and Repeat

Now rinse and repeat this process for every new piece of tech you want to learn.

It will solidify your knowledge and build your portfolio and online presence at the same time.

Once you have this process down, it will get easier and easier every time you want to learn something new. I highly recommend you follow a process similar to this when you want to learn a new stack.

The more you do it, the more you will learn and the more your portfolio and proof of skill will grow. This is how you can leverage learning to code into work as a professional developer.

For more actionable information like this on how to start and grow a successful dev career, check out my free 10-day email course, Launch Your Dev Career. It's a step-by-step guide to landing your first job as a developer.

We go over how to build an online presence, networking, building an impressive portfolio, and more, all designed to help you launch and grow a successful, fulfilling career as a developer.

The key aspects of a JAMstack application are the following:

• The entire app runs on a CDN (or ADN). CDN stands for Content Delivery Network and an ADN is an Application Delivery Network.
• Everything is in Git.
• Automated builds run with a workflow when developers push the code.
• There's Automatic deployment of the pre-built markup to the CDN/ADN.
• It's practically Serverless. To put it more clearly, we do not maintain any server-side applications but rather make use of already existing services (like email, media, database, search, and so on).

And here's a fun fact: Many of the features that once required a custom back-end can now be done entirely on the front-end.

In this article, we will learn how to build a JAMstack application that has:

• an API service to serve media files,
• and a Static Site Generator(SSG) to create the pre-built markup.

And finally we'll deploy it over a CDN.

So, what are we building today?

We will build an image gallery. I love movies, so I have decided to create an image gallery of my favorite actors. I have a fun name for it to: imaginary.

We will use a media management service called Cloudinary to host and manage our images. It also provides developer APIs to upload and fetch media such as images, videos, and so on

We will use a framework called Gatsby to build the front-end of the image gallery. Gatsby is a React-based open-source framework for creating websites and apps.

Finally, we will learn how to deploy the app to a CDN with an automatic build and deploy process. We will use Netlify CDN for this.

At the end of the article, our imaginary app will look like this:

Image Gallery app - Final Look

TL;DR

We will learn things with a step-by-step approach in this article. If you want to jump into the source code or demonstration sooner, here are links to them.

• You can access the image gallery demo from here: http://imaginary.netlify.app/
• All the source code used in this article is in my GitHub repo. Feel free to follow it, as I keep updating the source code frequently. If you liked the work, please support it with a star. https://github.com/atapas/imaginary/tree/1-freecodecamp-poc

Now let's get started.

How to Set Up Cloudinary

First, create an account with Cloudinary. A free plan is more than enough for our image gallery application.

Login using your account credentials to get to the Cloudinary dashboard. Please note down the Cloud name, API Key and, API Secret as we'll need them in our application.

Next, upload the images of your choice to use them in the image gallery. You can create a folder and call it whatever you want. In my case, I have named it artists and uploaded the images into it.

Note that we'll use this folder name later when we integrate Cloudinary with Gatsby.

Please select each of the images and add a Title and Description. We will use these two bits of meta information as image captions and alt-text, respectively, in our image gallery.

That's all. Please do not share the API secret and the key with anyone. Let's now go through the required setup for Gatsby.

How to Set Up Gatsby

A gatsby-based project needs node.js to work. Make sure you have Node.js installed. You can download and install node.js from here.

A successful install will show the Node version using this command:

node -v

Create a project directory

Create a project directory to organize the source code. Let's create a directory with the name imaginary.

mkdir imaginary

cd imaginary

Initialize the project

There are plenty of starter projects to create a gatsby app. While the starter projects simplify many complexities, at the same time they may be a bit overwhelming for a simple app like ours.

Keeping that in mind, we will initialize a simple gatsby project by ourselves.

Open a command prompt and type the following command to initialize a Node.js supported project:

npm init -y

Gatsby: Install and initial setup

Install the gatsby-cli tool globally. This tool will help us work with the Gatsby environment.

 npm install -g gatsby-cli

Install the Gatsby, React, and ReactDOM dependencies. You can either use the npm install command as above or the yarn add command if you have yarn installed.

 yarn add gatsby react react-dom

Let's also add a .gitignore file with the following content:

.cache
public
node_modules
*.env

You can optionally create a README.md and LICENSE file. At this stage, our project should have these folders and files:

Gatsby projects need a special configuration file called gatsby-config.js. At this time, we will need an empty file. Create a file named gatsby-config.js with the following content:

 module.exports = {
  // keep it empty    
 }

Now it is time to create our first page with Gatsby. Create a folder named src at the root of the project folder. Create a sub-folder named pages under src. Create a file named index.js under src/pages with the following content:

import React from 'react';    

  export default () => {    
   return (
      <>    
        <h1>Images to load here...</h1>
      </>        
    )    
  }

At this stage, our project files and folders should look like this:

Let's run it

Try the following command in the command prompt to run the app locally:

gatsby develop

By default, a gatsby app runs on the 8000 port number. Open your favorite browser and access the app @ http://localhost:8000.

You should see it running like you see in the screen-shot below:

That's all. Now, we've gotten both Cloudinary and Gatsby successfully set up. It's time to bring them together.

Cloudinary & Gatsby, the getting together story

The Gatsby framework has huge community support and there are many plug-ins to satisfy critical needs. In early 2020, the Cloudinary team introduced two super cool Gatsby plugins to the dev community:

• Gatsby-Source-Cloudinary - Helps in fetching the stored images at the build time from Cloudinary to a Gatsby app/site.
• Gatsby-Transformer-Cloudinary - Helps in uploading the local images from a Gatsby app/site to Cloudinary.

As we are only interested in fetching the images to the image gallery here, we will just install the gatsby-source-cloudinary plug-in.

We will also install a utility package called dotenv to handle the environment variables (Secret Key, API key, and so on) locally.

Let's install them. Open a command prompt and use the following command:

yarn add dotenv gatsby-source-cloudinary

Now, follow these steps to fetch the images into our app.

1. Create a .env file at the root of the project folder and add the following content to it. Please note that the values in the key-value pairs are available in the Cloudinary dashboard as we have seen before.

CLOUDINARY_CLOUD_NAME=<YOUR_CLOUDINARY_NAME>
CLOUDINARY_API_KEY=<YOUR_CLOUDINARY_API_KEY>
CLOUDINARY_API_SECRET=<YOUR_CLOUDINARY_API_SECRET>

2. Edit the gatby-config.js file to add the following content:

require('dotenv').config();

module.exports = {

    plugins:[
        {
            resolve: `gatsby-source-cloudinary`,
            options: {
              cloudName: process.env.CLOUDINARY_CLOUD_NAME,
              apiKey: process.env.CLOUDINARY_API_KEY,
              apiSecret: process.env.CLOUDINARY_API_SECRET,
              resourceType: `image`,
              prefix: `artists/` ,
              context: true,
              tags: true,
              maxResults: 50
            }
          }
    ]

}

There are a few things going on here. We are telling gatsby to use the gatsby-source-cloudinary plug-in with a few parameters.

The parameters cloudName, apiKey and apiSecret are fetched from the .env file using the dotenv package. We also specify the resourceType value as image as we are not interested in fetching other types of media.

The prefix parameter value should be the same as the image folder name in Cloudinary.

We specify context and tags as true to fetch the contextual metadata and tag information of an image. We also set the maxResults as 50 so that we do not get constrained with the default value of 10.

3. Next, create a folder called components under src and create a file called Gallery.js inside it. Gatsby uses graphQL to query the data from various sources like markdown, JSON, and Excel.

In our case, we will use Cludinary as a source to query the images using the gatsby-source-cloudinary plug-in configured already.

4. Now edit the Gallery.js file and add the following content:

import React from 'react';
import {useStaticQuery, graphql} from 'gatsby';

const Gallery = () => {
    const data = useStaticQuery(
        graphql`
        query CloudinaryImage {
            allCloudinaryMedia {
            edges {
                node {
                    secure_url
                    context {
                        custom {
                            alt
                            caption
                        }
                    }
                    resource_type
                }
            }
            }
        }`
    );
    const images = data.allCloudinaryMedia.edges;
    return (
        <div className="container">
            {images.map((image, index) => (
                <figure className="wave" key={`${index}-image`}>
                    <img 
                        src={image.node.secure_url} 
                        alt={image.node.context.custom.alt} >
                    </img>
                    <figcaption>{image.node.context.custom.caption}</figcaption>
                </figure>
                ))
            }
        </div>
    )
};

export default Gallery;

As we see above, we use a graphQL query to fetch the source image paths and the context information. We use the information to loop through and add the images with a caption.

5. The next step is to edit the index.js file to import the Gallery.js file and use it.

import React from 'react';
import Gallery from '../components/Gallery';

export default () => {    
    return (
      <>    
        <Gallery />
      </>        
    )    
}

If you are running the gatsby develop already, please stop it and run it again. Access the app again in the browser. You should see the app with all the images fetched from Cloudinary.

But wait, it doesn't look as elegant as was promised. We have to do some css work here.

Create a file called gallery.css under the folder src\components and add the following content in it:

body {
    background: #000000 url("https://res.cloudinary.com/atapas/image/upload/v1602214656/misc/6284_n48wtw.jpg") repeat-x center top;
    color: #FFFFFF;
}

.container {
    margin-top: 55px;
}

.wave {
    float: left;
    margin: 20px;
    animation: wave 
               ease-in-out 
               1s 
               infinite 
               alternate;
    transform-origin: center -20px;
}

.wave:hover {
    animation-play-state: paused;
}

.wave img {
    border: 5px solid #f8f8f8;
    display: block;
    width: 200px;
    height: 250px;
    background-color: #000;
}

.wave figcaption {
    text-align: center;
}

.wave:after{
    content: '';
    position: absolute;
    width: 20px; 
    height: 20px;
    border: 1.5px solid #ffffff;
    top: -10px; 
    left: 50%;
    z-index: 0;
    border-bottom: none;
    border-right: none;
    transform: rotate(45deg);
}

.wave:before{
    content: '';
    position: absolute;
    top: -23px;
    left: 50%;
    display: block;
    height: 44px;
    width: 47px;
    background-image: url(https://res.cloudinary.com/atapas/image/upload/v1602212639/misc/screw-head_oglfcu.png);
    background-size: 20px 20px;
    background-repeat: no-repeat;
    z-index: 16;
}

@keyframes wave {
    0% { transform: rotate(3deg); }
    100% { transform: rotate(-3deg); }
}

6. Import the gallery.css file into the Gallery.js file as

import './gallery.css';

That's all. You should see the app looking much better than before as if the images are hanging from a wall with animation in them.

Let's Deploy the App

The last step is to deploy the app publicly so that we show it off.

First, create a repository in GitHub and push the source code. Then create an account with Netlify to login.

Follow these simple steps to deploy your app to the Netlify CDN with built-in CI/CD support.

• Create a new site from Git
• Authenticate to your Github account and select the image gallery project. In my case, the project name is imaginary.
• In the next step, provide information about the build command as gatsby build and publish the directory as public/.
• Next click on the Site settings to tell netlify about the Cloudinary cloud name, secret key, API key, and so on.
• Browse to the Environment option and click on the Edit variables button.
• Add three variables as shown below with the values shown in your Cloudinary dashboard.
• Browse to the Deploys option and trigger a fresh deploy.
• You can change the site name to something that meets your needs. In my case, it is https://imaginary.netlify.app/:

New site from Git

Create a new site

Parameters for the site

Site settings

Add environment variables

Add all of them

Trigger a fresh deploy

Optionally to change the site name

Now we're done. We have the app up and running publicly.

In Summary

Hope you enjoyed reading this article. In a future article we will see how to use the other gatsby-cloudinary plug-in to upload an image to the Cloudinary server to add to our image gallery.

You may also like these articles:

• I made a photo gallery with CSS animation. Here’s what I learned.
• JAMstack for All: An Introduction
• What is a Static Site Generator and how to select one?

If this article was useful, please share it so others can read it as well. You can @ me on Twitter (@tapasadhikary) with comments, or feel free to follow me.

How can we leverage the web framework Next.js and hosting platform Vercel to build and deploy performant and reliable web apps?

Note: This is a preview of my Jamstack Handbook, a guide to everything you need to know about the Jamstack. It has 3 tutorials, including this one. Get your copy and learn how to build fast, dynamic apps with JavaScript and the static web.

• What will we build?
• Step 1: Getting started with a Next.JS React app
• Step 2: Setting up the project with Git
• Step 3: Deploying Next.js with Vercel
• What did we just deploy?
• Understanding modern CI / CD with Git
• Make a change and watch it automatically deploy
• What did we learn?

Next.js is a web framework that’s built and maintained by Vercel. Next.js makes it easy to spin up a new React application and provides a ton of features out of the box like server side rendering (SSR) and static site generation (SSG).

What will we build?

Our project itself will be relatively simple. We’re going to use the default Next.js Starter as a way to easily bootstrap the project, learn how to configure Next.js to statically compile, and then deploy that project with our customizations to Vercel.

A Starter is a template that allows developers to recreate that template from the command line. When installing the starter, the framework will set up the project and install all dependencies.

Step 1: Getting started with a Next.JS React app

To get started, we first want to navigate to the directory we want to create our project in.

We’ll use a Starter to create our project. To do this, we have two options for a package manager to use: yarn or npm. You can choose whichever you feel more comfortable with for the remainder of the walkthrough.

yarn create next-app
# or
npx create-next-app

Creating a new Next.js app

When running this command, Next.js will first ask you for a project name. Here we can use any name we want to identify the project. I’m going to use my-nextjs-app.

Naming a Next.js project

Once installation is finished, we’re now ready to get started with Next.js.

Navigate in your terminal to the new directory where your project is located and run:

yarn dev
# or
npm run dev

This will start your development server, which will make your new site available at http://localhost:3000.

Starting Next.js development server

If you open up your http://localhost:3000 address, you should now see the Next.js default project!

New Next.js app

Step 2: Setting up the project with Git

You'll want to set this next step up on your own. Create a new repository with your favorite Git provider that’s supported by Vercel.

At the time of writing this, Vercel supports GitHub, Gitlab, and Bitbucket.

If you’re choosing a provider for the first time, GitHub is a solid option and is easy to get started.

You’ll then want to add your project to that new repository and push the project up to Git.

Need help? Check out “Adding an existing project to GitHub using the command line” https://docs.github.com/en/github/importing-your-projects-to-github/adding-an-existing-project-to-github-using-the-command-line

For the rest of this walkthrough, I’ll be referencing GitHub, but the instructions should be the same for any supported provider.

Next.js app on GitHub

Step 3: Deploying Next.js with Vercel

Once your project is set up with GitHub, navigate to vercel.com and log in.

If you don’t already have a Vercel account, you should create one now. I would recommend creating an account with your GitHub account as it will help you import your project.

Inside the Vercel dashboard, click Import Project.

Import project to Vercel

Next, under Import Git Repository, click Continue.

Import Git repository to Vercel

Vercel will now ask for the repository URL. This will be the homepage for the repository you just created for your project.

Add Git repo URL to Vercel

After you click Continue, Vercel has already detected that your project uses Next.js. This means that we don’t need to set up and custom configurations, and we can hit Deploy!

Deploy Next.js project to Vercel

At this point, Vercel will get to work and start to build the new project and deploy it to their infrastructure.

Once it’s finished, it will congratulate you and give you a link to visit your site.

Vercel project successfully deployed

Click Visit and you’ll be directed to your project live on the internet:

Next.js app live

What did we just deploy?

We just created a new React app with Next.js and deployed it to Vercel.

We’ll walk through each specific step:

• Create Next App: We first created a new Next.js project on our computer. This provided us with a new React application complete with dependencies and code to get started with a basic website.
• Add Project to Git: We added our new Next.js project to a Git repository online that’s supported by Vercel. This allows us to easily interface with the project with other services like Vercel.
• Connect Git to Vercel: We imported our project from Git into Vercel. This allowed Vercel to interact with our code.
• Build & Deploy with Vercel: Vercel downloaded our code, was able to recognize it was a Next.js project, built our project, and deployed the compiled output to its infrastructure and made it available on the web.

If you were waiting for more steps to get your project out to the world, there are none! The entry point for publishing a new React project is now lower than it’s ever been and Next.js and Vercel are helping you get there.

Understanding modern CI / CD with Git

Another benefit of modern infrastructure providers like Vercel, is that when utilizing GitHub as a service connection, Vercel can watch for changes on our main branch.

Once Vercel recognizes that a change was made, it will download the latest code and re-run the same process as we did the first time (aside from any caching and optimization).

This means that any time we have new changes to our production branch, they’ll automatically be deployed.

Make a change and watch it automatically deploy

To test out the automatic deployments, let’s make a change to our project.

Inside our project, let’s make a change to some of the page content inside of pages/index.js. I’m going to change the title to “Colby’s Next.js Project”.

<h1 className={styles.title}>
  Colby's Next.js App
</h1>

Next.js app with change

Next, commit this change to your main Git branch and push it up to GitHub.

If you wait a few seconds and navigate back to vercel.com, find your project and click on the Deployments tab.

Vercel deployment when change detected

You’ll see that your project is now running or might have already finished if you weren’t quick enough. Now if you open your website link again, you’ll see the changes deployed!

Deployed changed Next.js app to Vercel

What did we learn?

Next.js is a web framework that allows us to quickly and easily spin up a new React application.

This, along with other similar frameworks, can be useful to get immediately productive instead of spending time building the project framework ourselves.

Vercel is a hosting and deployment platform that allows us to integrate with our favorite supported Git provider. Once connected, Vercel will download our project, build our project, and deploy the output to the internet.

Modern infrastructure tools like Vercel will watch for changes on our Git repository and will build and deploy our project so that we’re always seeing the latest version.

Learn more about the Jamstack!

You can learn more about the Jamstack, including 2 more in depth tutorials, with my Jamstack Handbook.

Order at jamstackhandbook.com

One of the reasons we create JAMstack sites is because of their great performance. Serving static files is easy and quick. But what if we upgrade the visitor's experience and make the site available offline?

Looking at both recent reports on the State of the JAMstack in 2020 (you can check out Kontent's report and Netlify's report) it's clear that performance is the main reason we are building static sites.

I call this fact a bit of a cheat. Performance benefit comes with the JAMstack by design, so it's like calling puppies cute. They're always cute because they're puppies.

If we're really serious about performance, though, even JAMstack sites can do better. But before we can dive into offline mode for Gatsby, we must understand how Gatsby serves pages:

The visitor does not request every single HTML file from the server. Rather, Gatsby's JS client asks the server for the page-data.json of the respective page. That's how the visitor transitions into the requested page without that classic page reload. But even for that we need the network.

Why do websites even need an offline mode?

These days, everyone is online, right? An internet connection in mobile phones no longer seems like an option, but a requirement. We use apps like Whatsapp, Messenger, and others all the time.

But what if we step inside an elevator? What if we're walking to a car parked in an underground garage or driving through a tunnel? What if we're inside a plane that's about to take off?

No reception. That's what all these places share. And the only thing people can do with their phones without reception is to watch downloaded Netflix movies. Until you enable offline mode for your website.

How does it work?

In a nutshell, we save the visitor the round-trip to the server and download all the necessary data in advance. And we install a ServiceWorker which acts as a server instead of a real remote server.

A ServiceWorker is a script that the visitor's browser runs in the background and enables features like push notifications and others. See Google docs for more information.

With Gatsby, just like we're all used to, it's as simple as installing a plugin:

npm i gatsby-offline-plugin --save

And adding it to the gatsby-config.js:

plugins: [
    ...
    `gatsby-plugin-offline`,
    ...
]

But every website uses many different types of assets, so typically, we need to take one additional step and configure the service worker.

Assets serving strategies

Every website contains many assets ranging from CSS files through images and icons to web fonts and actual page data.

The service worker cannot really download all these assets during the first page load as that would go directly against the performance benefit. Visitors would also not be happy if their browsers started downloading 100MB of images the moment they decided to visit your photo gallery.

We can use regular expressions to target specific files and configure the service worker to treat them appropriately. Let's take a look at the available strategies:

CacheFirst

Typical use: web fonts, stylesheets

The service worker checks the cache for the requested file. If the file's missing, it goes online to fetch it while storing it in the cache for future use.

Image credit: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

CacheOnly

Possible use: your own pre-caching logic

The service worker checks the cache for the requested file. If the file's missing, it returns an error.

Image credit: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

NetworkFirst

Typical use: non-critical API requests

The service worker goes online to fetch the requested file. If the network is down or server unresponsive, it falls back to the cache.

Image credit: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

NetworkOnly

Typical use: critical API requests

The service worker goes online to fetch the requested file. If the network is down or server unresponsive, it returns an error.

Image credit: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

StaleWhileRevalidate

Typical use: front-end assets, images

The service worker checks the cache for the requested file and provides it. Subsequently, it makes a network request to silently update the cache.

Image credit: https://developers.google.com/web/tools/workbox/modules/workbox-strategies

Configuring the Gatsby site

A simple configuration of a Gatsby site that should work offline looks like this:

{
    resolve: `gatsby-plugin-offline`,
    options: {
        precachePages: [`/blog/*`],
    },
}

This way I'm configuring the service worker to pre-cache all blog posts, which are all pages whose URL starts with /blog/.

Once the visitor accesses the index page with links to blog posts, they will be able to click-through to any of them without an active internet connection. That is, if you use the Link element in the implementation. Standard anchor tags make a browser go around the service worker and fetch data from remote.

The service worker will treat all assets according to its default configuration:

• CacheFirst
  JS files, CSS files, everything inside folder "static/"
• NetworkFirst
  /page-data//page-data.json files
• StaleWhileRevalidate
  images, web font files, etc.

So if you're worried that the service worker will fetch all assets of all blog posts, it will do so only after the visitor actually opens the blog post page.

The reason is, cache space and the visitor's internet connection bandwidth are limited. On the first page load, the visitor downloads all the site-wide assets like stylesheets, web fonts, icons, and others, so these assets will be available in the cache on subsequent loads. Images and other resources of pre-cached pages will be resolved once the page is requested and this can be changed only via custom logic.

So in which cases would you want to change the config? There were actually not many cases I could come up with, but I did stumble upon a few:

• Assets provided from URLs without matching filename suffix
  Google serves CSS definitions of web fonts without the .css suffix and that is already covered by the default config. However, you may be serving images or other assets from URLs that don't have the appropriate suffix.
• Gain more control over the cache
  With some assets you want to be in charge of how long a certain item can reside in cache until it becomes expired.
• Exotic assets
  Alright, exotic may be a bit strong word :-) but web fonts in EOT format, pictures in HEIC format, short videos, songs, etc.

In these cases you need to adjust the default configuration and define it within the plugin options:

{
  resolve: `gatsby-plugin-offline`,
  options: {
    precachePages: [`/blog/*`],
    runtimeCaching: [
      // previous definitions from the default config
      (...),
      {
        urlPattern: /^https:\/\/fonts\.gstatic\.com/,
        handler: 'cacheFirst',
        options: {
          cacheableResponse: {
            statuses: [0, 200]
          },
          cacheName: 'google-fonts-webfonts',
          expiration: {
            maxAgeSeconds: 60 * 60,
            maxEntries: 30
          }
        }
      },
    ]
  },
},

This additional config item will ensure that at most 30 Google fonts served from gstatic.com will be cached for a maximum duration of one hour and will be handled using the CacheFirst strategy.

Build the Site Before Testing

Once you are finished with the configuration, make sure to build and serve the site before testing the offline capabilities. They don't work in development mode.

gatsby build && gatsby serve

JAMstack = performance, but...

In this article I showed you how to install and configure the offline plugin for Gatsby.

All JAMstack sites come with the great benefit of amazing performance by design. By adding offline capabilities, you are taking the browsing experience of your visitors to the next level compared to other JAMstack sites. The service worker configuration allows you to further fine-tune how each asset will be handled and cached.

If you're interested, you can find more information about the plugin in the Gatsby docs.

I recently took on the task of creating a documentation site theme for two projects. Both projects needed the same basic features, but one uses Jekyll while the other uses Hugo.

In typical developer rationality, there was clearly only one option. I decided to create the same theme in both frameworks, and to give you, dear reader, a side-by-side comparison.

This post isn’t a comprehensive theme-building guide, but is rather intended to familiarize you with the process of building a theme in either generator. Here's what we'll cover:

• How theme files are organized
• Where to put content
• How templating works
• Creating a top-level menu with the pages object
• Creating a menu with nested links from a data list
• Putting the template together
• Creating styles
• How to configure and deploy to GitHub Pages

Here’s a crappy wireframe of the theme I’m going to create.

If you’re planning to build-along, it may be helpful to serve the theme locally as you build it – and both generators offer this functionality. For Jekyll, run jekyll serve, and for Hugo, hugo serve.

There are two main elements: the main content area, and the all-important sidebar menu. To create them, you’ll need template files that tell the site generator how to generate the HTML page. To organize theme template files in a sensible way, you first need to know what directory structure the site generator expects.

How theme files are organized

Jekyll supports gem-based themes, which users can install like any other Ruby gems. This method hides theme files in the gem, so for the purposes of this comparison, we aren’t using gem-based themes.

When you run jekyll new-theme <name>, Jekyll will scaffold a new theme for you. Here’s what those files look like:

.
├── assets
├── Gemfile
├── _includes
├── _layouts
│   ├── default.html
│   ├── page.html
│   └── post.html
├── LICENSE.txt
├── README.md
├── _sass
└── <name>.gemspec

The directory names are appropriately descriptive. The _includes directory is for small bits of code that you reuse in different places, in much the same way you’d put butter on everything. (Just me?)

The _layouts directory contains templates for different types of pages on your site. The _sass folder is for Sass files used to build your site’s stylesheet.

You can scaffold a new Hugo theme by running hugo new theme <name>. It has these files:

.
├── archetypes
│   └── default.md
├── layouts
│   ├── 404.html
│   ├── _default
│   │   ├── baseof.html
│   │   ├── list.html
│   │   └── single.html
│   ├── index.html
│   └── partials
│       ├── footer.html
│       ├── header.html
│       └── head.html
├── LICENSE
├── static
│   ├── css
│   └── js
└── theme.toml

You can see some similarities. Hugo’s page template files are tucked into layouts/. Note that the _default page type has files for a list.html and a single.html.

Unlike Jekyll, Hugo uses these specific file names to distinguish between list pages (like a page with links to all your blog posts on it) and single pages (like one of your blog posts). The layouts/partials/ directory contains the buttery reusable bits, and stylesheet files have a spot picked out in static/css/.

These directory structures aren’t set in stone, as both site generators allow some measure of customization. For example, Jekyll lets you define collections, and Hugo makes use of page bundles. These features let you organize your content multiple ways, but for now, let's look at where to put some simple pages.

Where to put content

To create a site menu that looks like this:

Introduction
    Getting Started
    Configuration
    Deploying
Advanced Usage
    All Configuration Settings
    Customizing
    Help and Support

You’ll need two sections (“Introduction” and “Advanced Usage”) containing their respective subsections.

Jekyll isn’t strict with its content location. It expects pages in the root of your site, and will build whatever’s there. Here’s how you might organize these pages in your Jekyll site root:

.
├── 404.html
├── assets
├── Gemfile
├── _includes
├── index.markdown
├── intro
│   ├── config.md
│   ├── deploy.md
│   ├── index.md
│   └── quickstart.md
├── _layouts
│   ├── default.html
│   ├── page.html
│   └── post.html
├── LICENSE.txt
├── README.md
├── _sass
├── <name>.gemspec
└── usage
    ├── customizing.md
    ├── index.md
    ├── settings.md
    └── support.md

You can change the location of the site source in your Jekyll configuration.

In Hugo, all rendered content is expected in the content/ folder. This prevents Hugo from trying to render pages you don’t want, such as 404.html, as site content. Here’s how you might organize your content/ directory in Hugo:

.
├── _index.md
├── intro
│   ├── config.md
│   ├── deploy.md
│   ├── _index.md
│   └── quickstart.md
└── usage
    ├── customizing.md
    ├── _index.md
    ├── settings.md
    └── support.md

To Hugo, _index.md and index.md mean different things. It can be helpful to know what kind of Page Bundle you want for each section: Leaf, which has no children, or Branch.

Now that you have some idea of where to put things, let’s look at how to build a page template.

How templating works

Jekyll page templates are built with the Liquid templating language. It uses braces to output variable content to a page, such as the page’s title: {{ page.title }}.

Hugo’s templates also use braces, but they’re built with Go Templates. The syntax is similar, but different: {{ .Title }}.

Both Liquid and Go Templates can handle logic. Liquid uses tags syntax to denote logic operations:

{% if user %}
  Hello {{ user.name }}!
{% endif %}

And Go Templates places its functions and arguments in its braces syntax:

{{ if .User }}
    Hello {{ .User }}!
{{ end }}

Templating languages allow you to build one skeleton HTML page, then tell the site generator to put variable content in areas you define. Let’s compare two possible default page templates for Jekyll and Hugo.

Jekyll’s scaffold default theme is bare, so we’ll look at their starter theme Minima. Here’s _layouts/default.html in Jekyll (Liquid):

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">

  {%- include head.html -%}

  <body>

    {%- include header.html -%}

    <main class="page-content" aria-label="Content">
      <div class="wrapper">
        {{ content }}
      </div>
    </main>

    {%- include footer.html -%}

  </body>

</html>

Here’s Hugo’s scaffold theme layouts/_default/baseof.html (Go Templates):

<!DOCTYPE html>
<html>
    {{- partial "head.html" . -}}
    <body>
        {{- partial "header.html" . -}}
        <div id="content">
        {{- block "main" . }}{{- end }}
        </div>
        {{- partial "footer.html" . -}}
    </body>
</html>

Different syntax, same idea. Both templates pull in reusable bits for head.html, header.html, and footer.html. These show up on a lot of pages, so it makes sense not to have to repeat yourself.

Both templates also have a spot for the main content, though the Jekyll template uses a variable ({{ content }}) while Hugo uses a block ({{- block "main" . }}{{- end }}). Blocks are just another way Hugo lets you define reusable bits.

Now that you know how templating works, you can build the sidebar menu for the theme.

Creating a top-level menu with the pages object

You can programmatically create a top-level menu from your pages. It will look like this:

Introduction
Advanced Usage

Let’s start with Jekyll. You can display links to site pages in your Liquid template by iterating through the site.pages object that Jekyll provides and building a list:

<ul>
    {% for page in site.pages %}
    <li><a href="{{ page.url | absolute_url }}">{{ page.title }}</a></li>
    {% endfor %}
</ul>

This returns all of the site’s pages, including all the ones that you might not want, like 404.html. You can filter for the pages you actually want with a couple more tags, such as conditionally including pages if they have a section: true parameter set:

<ul>
    {% for page in site.pages %}
    {%- if page.section -%}
    <li><a href="{{ page.url | absolute_url }}">{{ page.title }}</a></li>
    {%- endif -%}
    {% endfor %}
</ul>

You can achieve the same effect with slightly less code in Hugo. Loop through Hugo’s .Pages object using Go Template’s range action:

<ul>
{{ range .Pages }}
    <li>
        <a href="{{.Permalink}}">{{.Title}}</a>
    </li>
{{ end }}
</ul>

This template uses the .Pages object to return all the top-level pages in content/ of your Hugo site. Since Hugo uses a specific folder for the site content you want rendered, there’s no additional filtering necessary to build a simple menu of site pages.

Creating a menu with nested links from a data list

Both site generators can use a separately defined data list of links to render a menu in your template. This is more suitable for creating nested links, like this:

Introduction
    Getting Started
    Configuration
    Deploying
Advanced Usage
    All Configuration Settings
    Customizing
    Help and Support

Jekyll supports data files in a few formats, including YAML. Here’s the definition for the menu above in _data/menu.yml:

section:
  - page: Introduction
    url: /intro
    subsection:
      - page: Getting Started
        url: /intro/quickstart
      - page: Configuration
        url: /intro/config
      - page: Deploying
        url: /intro/deploy
  - page: Advanced Usage
    url: /usage
    subsection:
      - page: Customizing
        url: /usage/customizing
      - page: All Configuration Settings
        url: /usage/settings
      - page: Help and Support
        url: /usage/support

Here’s how to render the data in the sidebar template:

{% for a in site.data.menu.section %}
<a href="{{ a.url }}">{{ a.page }}</a>
<ul>
    {% for b in a.subsection %}
    <li><a href="{{ b.url }}">{{ b.page }}</a></li>
    {% endfor %}
</ul>
{% endfor %}

This method allows you to build a custom menu, two nesting levels deep. The nesting levels are limited by the for loops in the template. For a recursive version that handles further levels of nesting, see Nested tree navigation with recursion.

Hugo does something similar with its menu templates. You can define menu links in your Hugo site config, and even add useful properties that Hugo understands, like weighting. Here’s a definition of the menu above in config.yaml:

sectionPagesMenu: main

menu:  
  main:
    - identifier: intro
      name: Introduction
      url: /intro/
      weight: 1
    - name: Getting Started
      parent: intro
      url: /intro/quickstart/
      weight: 1
    - name: Configuration
      parent: intro
      url: /intro/config/
      weight: 2
    - name: Deploying
      parent: intro
      url: /intro/deploy/
      weight: 3
    - identifier: usage
      name: Advanced Usage
      url: /usage/
    - name: Customizing
      parent: usage
      url: /usage/customizing/
      weight: 2
    - name: All Configuration Settings
      parent: usage
      url: /usage/settings/
      weight: 1
    - name: Help and Support
      parent: usage
      url: /usage/support/
      weight: 3

Hugo uses the identifier, which must match the section name, along with the parent variable to handle nesting. Here’s how to render the menu in the sidebar template:

<ul>
    {{ range .Site.Menus.main }}
    {{ if .HasChildren }}
    <li>
        <a href="{{ .URL }}">{{ .Name }}</a>
    </li>
    <ul class="sub-menu">
        {{ range .Children }}
        <li>
            <a href="{{ .URL }}">{{ .Name }}</a>
        </li>
        {{ end }}
    </ul>
    {{ else }}
    <li>
        <a href="{{ .URL }}">{{ .Name }}</a>
    </li>
    {{ end }}
    {{ end }}
</ul>

The range function iterates over the menu data, and Hugo’s .Children variable handles nested pages for you.

Putting the template together

With your menu in your reusable sidebar bit (_includes/sidebar.html for Jekyll and partials/sidebar.html for Hugo), you can add it to the default.html template.

In Jekyll:

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">

{%- include head.html -%}

<body>
    {%- include sidebar.html -%}

    {%- include header.html -%}

    <div id="content" class="page-content" aria-label="Content">
        {{ content }}
    </div>

    {%- include footer.html -%}

</body>

</html>

In Hugo:

<!DOCTYPE html>
<html>
{{- partial "head.html" . -}}

<body>
    {{- partial "sidebar.html" . -}}

    {{- partial "header.html" . -}}
    <div id="content" class="page-content" aria-label="Content">
        {{- block "main" . }}{{- end }}
    </div>
    {{- partial "footer.html" . -}}
</body>

</html>

When the site is generated, each page will contain all the code from your sidebar.html.

Create a stylesheet

Both site generators accept Sass for creating CSS stylesheets. Jekyll has Sass processing built in, and Hugo uses Hugo Pipes. Both options have some quirks.

Sass and CSS in Jekyll

To process a Sass file in Jekyll, create your style definitions in the _sass directory. For example, in a file at _sass/style-definitions.scss:

$background-color: #eef !default;
$text-color: #111 !default;

body {
  background-color: $background-color;
  color: $text-color;
}

Jekyll won’t generate this file directly, as it only processes files with front matter. To create the end-result filepath for your site’s stylesheet, use a placeholder with empty front matter where you want the .css file to appear. For example, assets/css/style.scss. In this file, simply import your styles:

---
---

@import "style-definitions";

This rather hackish configuration has an upside: you can use Liquid template tags and variables in your placeholder file. This is a nice way to allow users to set variables from the site _config.yml, for example.

The resulting CSS stylesheet in your generated site has the path /assets/css/style.css. You can link to it in your site’s head.html using:

<link rel="stylesheet" href="{{ "/assets/css/style.css" | relative_url }}" media="screen">

Sass and Hugo Pipes in Hugo

Hugo uses Hugo Pipes to process Sass to CSS. You can achieve this by using Hugo’s asset processing function, resources.ToCSS, which expects a source in the assets/ directory. It takes the SCSS file as an argument.

With your style definitions in a Sass file at assets/sass/style.scss, here’s how to get, process, and link your Sass in your theme’s head.html:

{{ $style := resources.Get "/sass/style.scss" | resources.ToCSS }}
<link rel="stylesheet" href="{{ $style.RelPermalink }}" media="screen">

Hugo asset processing requires extended Hugo, which you may not have by default. You can get extended Hugo from the releases page.

Configure and deploy to GitHub Pages

Before your site generator can build your site, it needs a configuration file to set some necessary parameters. Configuration files live in the site root directory. Among other settings, you can declare the name of the theme to use when building the site.

Configure Jekyll

Here’s a minimal _config.yml for Jekyll:

title: Your awesome title
description: >- # this means to ignore newlines until "baseurl:"
  Write an awesome description for your new site here. You can edit this
  line in _config.yml. It will appear in your document head meta (for
  Google search results) and in your feed.xml site description.
baseurl: "" # the subpath of your site, e.g. /blog
url: "" # the base hostname & protocol for your site, e.g. http://example.com
theme: # for gem-based themes
remote_theme: # for themes hosted on GitHub, when used with GitHub Pages

With remote_theme, any Jekyll theme hosted on GitHub can be used with sites hosted on GitHub Pages.

Jekyll has a default configuration, so any parameters added to your configuration file will override the defaults. Here are additional configuration settings.

Configure Hugo

Here’s a minimal example of Hugo’s config.yml:

baseURL: https://example.com/ # The full domain your site will live at
languageCode: en-us
title: Hugo Docs Site
theme: # theme name

Hugo makes no assumptions, so if a necessary parameter is missing, you’ll see a warning when building or serving your site. Here are all configuration settings for Hugo.

Deploy to GitHub Pages

Both generators build your site with a command.

For Jekyll, use jekyll build. See further build options here.

For Hugo, use hugo. You can run hugo help or see further build options here.

You’ll have to choose the source for your GitHub Pages site. Once done, your site will update each time you push a new build. Of course, you can also automate your GitHub Pages build using GitHub Actions. Here’s one for building and deploying with Hugo, and one for building and deploying Jekyll.

Showtime!

All the substantial differences between these two generators are under the hood. All the same, let’s take a look at the finished themes, in two color variations.

Here’s Hugo:

Here's Jekyll:

Wait who won?

?

Both Hugo and Jekyll have their quirks and conveniences.

From this developer’s perspective, Jekyll is a workable choice for simple sites without complicated organizational needs. If you’re looking to render some one-page posts in an available theme and host with GitHub Pages, Jekyll will get you up and running fairly quickly.

Personally, I use Hugo. I like the organizational capabilities of its Page Bundles, and it’s backed by a dedicated and conscientious team that really seems to strive to facilitate convenience for their users. This is evident in Hugo’s many functions, and handy tricks like Image Processing and Shortcodes. They seem to release new fixes and versions about as often as I make a new cup of coffee - which, depending on your use case, may be fantastic, or annoying.

If you still can’t decide, don’t worry. The OpenGitDocs documentation theme I created is available for both Hugo and Jekyll. Start with one, switch later if you want. That’s the benefit of having options.

• What are we going to build?
• What is Mapbox?
• Part 1: Creating a custom Mapbox style
• Part 2: Adding a custom TileLayer to React Leaflet
• Part 3: Adding a custom basemap to Gatsby Starter Leaflet
• Securing your Mapbox key
• Want to learn more about maps?

What are we going to build?

We’re going to walk through creating a new basic Mapbox style in our Mapbox account. Once created, we’re going to use their Map API to add a custom basemap to our React Leaflet app.

Gatsby Starter Leaflet with Mapbox basemap

For our map, we’re going to use this Leaflet Gatsby Starter I created that will allow you to easily spin up a new mapping app. Before we spin that up though, I’ll walk you through how to add it using only React Leaflet components.

A mapping app?

Yup! Maps are used all around the world to study datasets for geographic locations. They're important tools for scientists and others that are trying to help the world.

Coronavirus (COVID-19) custom map

If you want to learn more about building a map and adding data to it, you can check out some of my other articles first such as creating a Coronavirus (COVID-19) map or a Summer Road Trip map as well as a little bit of inspiration about why Anyone Can Map.

What is Mapbox?

Mapbox is a mapping platform that allows its customers to create custom mapping solutions. They also leverage a variety of APIs that provide powerful capabilities for building map features.

mapbox.com

For our purposes, we’re going to utilize their Map API, specifically their Static Tiles API, to serve a custom map style that we create.

Part 1: Creating a custom Mapbox style

To get the look and feel that we want for our map, it’s important to have a basemap that helps make our data present itself without distractions. Plus, sometimes it’s fun to have a custom map.

Mapbox account

The first thing we’ll need to set up our custom Mapbox style is to have an account. I'm not going to walk you through that process, but you can head over to Mapbox’s website where you can sign up for free: mapbox.com

Creating a new custom style

Creating a new style in Mapbox isn’t as hard as it sounds. While it can get really complex if you want something unique, we can copy one of Mapbox’s default styles to get started.

First, head over to Mapbox’s Studio dashboard by clicking your account link in the top right corner when logged in.

Mapbox Studio

Once we’re on our Studio dashboard, we want to select the New Style button.

Create a new style in Mapbox Studio

After clicking the button, a modal will pop up allowing you to choose a template. You can choose whatever you want here, but I’m going to choose Monochrome with a variation of Dark. And after you’ve selected your template, click the Customize button.

Select and customize a template for a new style in Mapbox Studio

And now we’re dropped into our customization UI.

Mapbox customize style UI

From here, you can really do what you’d like. There are a ton of options to customize your map. It’s a little complex to try to dig in here, but Mapbox provides some resources to try to help you get productive.

Generating a Mapbox token

Once you’re happy with your new style and everything’s published, we want to generate a token that we’ll use for providing access to our Map.

Head on over to the Account section of the Mapbox dashboard.

Creating a new token in Mapbox

Mapbox provides you with a “default” token that you can use in your applications. You're free to use this, but I recommend creating a new token that you can provide a unique name, that way if you ever blow past the free tier of Mapbox, you’ll be able to track your usage.

Additionally, it’s best to keep a separate token for each application, that way you can easily rotate an individual key, without having to update every application using it.

Once you click Create a token, you can set up the key how you’d like, with the scopes and permissions you choose, but for our purposes, you can leave all of the Public scopes checked for our map, which they do by default.

Create a new access token in Mapbox

Configuring our custom endpoint

For this tutorial, we’re going to use Mapbox’s Static Tiles service.

Mapbox Static Tiles Maps API

Our endpoint will look like the following:

https://api.mapbox.com/styles/v1/{username}/{style_id}/tiles/256/{z}/{x}/{y}@2x?access_token={access_token}

There are a few parameters here we need to understand:

• username: this will be your Mapbox account’s username
• style_id: this will be the ID of the style you created before
• z, x, y: these are parameters that Leaflet programmatically swaps out, so we want to leave them as is
• access_token: this is the Mapbox key you created above

To find your username and style ID, we can use the Style URL for our new Mapbox style to get those values.

Finding the Style URL in Mapbox Studio

In my example, my Style URL looks like:

mapbox://styles/colbyfayock/ck8lryjfq0jdo1ip9ctmuhc6p

colbyfayock is my username and ck8lryjfq0jdo1ip9ctmuhc6p is my style ID.

And once I update my endpoint parameters, the final tilepoint URL will look like:

https://api.mapbox.com/styles/v1/colbyfayock/ck8lryjfq0jdo1ip9ctmuhc6p/tiles/256/{z}/{x}/{y}@2x?access_token=MYACCESSTOKEN

Part 2: Adding a custom TileLayer to React Leaflet

When building a map with React Leaflet, your main component will be a <Map> that wraps the entirety of the app. This is what sets up your Map instance for Leaflet.

For our purposes here, we’re going to use the example on the React Leaflet homepage as our starting point.

React Leaflet TileLayer Component

Inside of your <Map> component you include a <TileLayer> component, which defines the imagery of the world that you base your map upon.

The example on the React Leaflet homepage uses a public version of OpenStreetMap as their TileLayer, which is an open source map project created and updated by people all around the world.

<Map center={position} zoom={13}>
  <TileLayer
    url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"
    attribution="&copy; <a href=&quot;http://osm.org/copyright&quot;>OpenStreetMap</a> contributors"
  />
</Map>

This gives you a basic map, but we want to swap in Mapbox so we can set up a custom look and feel for our map.

Custom Mapbox TileLayer

To add our custom style, we’ll want to update the url and attribution props of the TileLayer component.

For URL, it will simply be the custom style endpoint we created earlier, so in my example, it looks like:

https://api.mapbox.com/styles/v1/colbyfayock/ck8lryjfq0jdo1ip9ctmuhc6p/tiles/256/{z}/{x}/{y}@2x?access_token=MYACCESSTOKEN

For attribution, we want to credit Mapbox as the service, so we want to set our attribution as:

Map data &copy; <a href=&quot;https://www.openstreetmap.org/&quot;>OpenStreetMap</a> contributors, <a href=&quot;https://creativecommons.org/licenses/by-sa/2.0/&quot;>CC-BY-SA</a>, Imagery &copy; <a href=&quot;https://www.mapbox.com/&quot;>Mapbox</a>

When plugged in to our TileLayer, our code should now look like this:

<Map center={position} zoom={13}>
  <TileLayer
    url="https://api.mapbox.com/styles/v1/colbyfayock/ck8lryjfq0jdo1ip9ctmuhc6p/tiles/256/{z}/{x}/{y}@2x?access_token=MYACCESSTOKEN"
    attribution="Map data &copy; <a href=&quot;https://www.openstreetmap.org/&quot;>OpenStreetMap</a> contributors, <a href=&quot;https://creativecommons.org/licenses/by-sa/2.0/&quot;>CC-BY-SA</a>, Imagery &copy; <a href=&quot;https://www.mapbox.com/&quot;>Mapbox</a>"
  />
</Map>

And once we open up our map, we should see our new basemap!

React Leaflet with a Mapbox basemap

See the code!

If you want to see how I did it, check out the diff commit by commit.

The only caveat there is I created an .env.development.local file in the root of my project in which I stored a new environment variable called REACT_APP_MAPBOX_KEY to store my Mapbox key.

Part 3: Adding a custom basemap to Gatsby Starter Leaflet

I’ve written a few other articles on how to get started with my Leaflet Gatsby Starter, but for this part, we’ll want to have a basic app spun up that we can use to change our TileLayer endpoint.

Setting up our React Leaflet Gatsby app

To get started, check out the instructions on the Starter github:

https://github.com/colbyfayock/gatsby-starter-leaflet

Once you’re ready, you should have a basic mapping app ready to go!

New Leaflet Gatsby app in the browser

Configuring our Mapbox service

The first thing we’ll want to do is add Mapbox as a service in our src/data/map-services.js file.

Taking our custom endpoint URL that we created in Part 1, let’s set up a new object with a name of Mapbox, and with a url and attribution similar to what we did in Part 2.

export const mapServices = [
  {
    name: ‘OpenStreetMap’,
    attribution: '&copy; <a href="http://osm.org/copyright”>OpenStreetMap</a> contributors’,
    url: ‘https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png’
  },
  {
    name: ‘Mapbox’,
    attribution: ‘Map data &copy; <a href=&quot;https://www.openstreetmap.org/&quot;>OpenStreetMap</a> contributors, <a href=&quot;https://creativecommons.org/licenses/by-sa/2.0/&quot;>CC-BY-SA</a>, Imagery &copy; <a href=&quot;https://www.mapbox.com/&quot;>Mapbox</a>’,
    url: `https://api.mapbox.com/styles/v1/colbyfayock/ck8c2foj72lqk1jnug0g2haw0/tiles/256/{z}/{x}/{y}@2x?access_token=MY_ACCESS_TOKEN`
  }
];

Using our Mapbox map service

Once you have your Mapbox service set up, all that’s left is to open up the src/pages/index.js file, find the mapSettings object definition, and update the defaultBaseMap property to Mapbox.

const mapSettings = {
  center: CENTER,
  defaultBaseMap: ‘Mapbox’,
  zoom: DEFAULT_ZOOM,
  mapEffect
};

Save that change, refresh the map in your browser, and you should now see your custom basemap style!

Gatsby Starter Leaflet with custom Mapbox basemap in browser

See the code!

If you want to see how I did it, check out the diff with the commit.

The only caveat there is I created an .env.development file in the root of my project in which I stored a new environment variable called GATSBY_MAPBOX_KEY to store my Mapbox key.

Securing your Mapbox key

Environment variables

Part of most development processes that use individual keys will generally set the keys up as environment variables. Environment variables are configured settings that don’t live in the code itself.

This is important because it prevents your key from being checked in to your code, which is bad from a security perspective, but it also allows you to provide a different key for different environments.

When generating your keys, try to keep this in mind, as it can save you in the long run.

Locking down your Mapbox key

In your settings when creating a token or when editing a token, Mapbox allows you to specify only the URLs you want your key to be accessible from.

Though Mapbox has a generous free tier, you probably want to keep it locked down only to the URLs that you’re using it on. You can create multiple keys, where one could be for public use on your website and one would be for your local development.

This is helpful for instance, where you have a key that will never be used publicly for development purposes, but then you have a key that you deploy with, which can be locked down only to that URL.

If someone grabs your key, they could plug it into their own website and use up all of your free tier, potentially running up your bill!

Want to learn more about maps?

You can check out a few of my other resources to get started:

• How to create a Coronavirus (COVID-19) Dashboard & Map App in React with Gatsby and Leaflet
• Anyone Can Map! Inspiration and an introduction to the world of mapping
• How to Create a Summer Road Trip Mapping App with Gatsby and Leaflet
• How to Create your own Santa Tracker with Gatsby and React Leaflet
• How to build a mapping app in React the easy way with Leaflet

• A little about AWS
• What are the benefits of serving from S3 and CloudFront?
• Before we start, you’ll need an AWS account
• Storing your website on S3
• Serving your website on S3
• Distributing your website on CloudFront
• Custom domain names
• Advanced AWS Usage
• Resources

A little about AWS

If you’re not familiar, AWS (Amazon Web Services) is a cloud service provider that gives developers opportunities to build pretty much anything they can imagine in the cloud.

Though their services extend beyond the likes of machine learning and artificial intelligence, we’re going to stick with the entry level services for the purpose of this guide that will allow us to easily host an HTML website.

Types of AWS services available

Building a site with S3 and CloudFront is a common recipe that small and high scale companies across the web use, but let’s break down what each service actually does.

Object storage with S3

S3 (Simple Storage Service) acts as your hosting for your static website. Think of it like a hard drive in the cloud which we’re not able to use it for processing purposes, but rather for simple file storage and access.

List of files from a static site in an AWS S3 bucket

When an app or website is compiled in static form, this is all we need to serve it to the people visiting our site. The HTML is sent in the initial request “as is” (unless there’s processing with your provider) and any additional work occurs after the page loads in the browser usually by JavaScript. This allows us to take this simple (and cheap) approach by serving these files from S3.

Content Delivery Network with CloudFront

CloudFront works as a CDN (Content Delivery Network) that sits in front of your website, caching the files, and serving them directly to the people visiting your site.

CDN Diagram

Where you host and serve your website from, typically called the origin, is the main source of your files and can serve the website itself. But putting a CDN in front of it provides the people accessing your content a shorter and faster way to make their request.

What are the benefits of serving from S3 and CloudFront?

Given the rise in the JAMstack era, many services are popping up that provide similar services for static sites that make it really easy to deploy. Some even come with a generous free tier like Netlify and Zeit!

But sometimes developers need a little bit more control over their services or they need to integrate into a larger cloud pipeline that’s already 99% percent in AWS, which is exactly where S3 shines. Also, chances are, during your first year you might still qualify for AWS’s free tier.

Fitting in to the AWS Well-Architected Framework

As a lead provider in cloud services, AWS has published many guides to help developers and teams strive for excellence in their solutions in terms of performance, cost, and security.

One particular guideline is their 5 pillars of what they describe as a “well-architected" infrastructure.

AWS Well-Architected Framework

By default, we check all of these boxes with our hosting solution by using S3 and CloudFront. Out of the box, the HTML and assets you serve will be fast, cheap, secure, and reliable.

The beauty of static and JAMstack sites

Building on top of the pillars, what you’re actually serving is a static HTML file and group of assets that won’t require any type of rendering resources on the initial request. Before this, a common problem was having to worry about a site crashing due to heavy load. But with S3 and CloudFront, your website is infinitely scalable.

On a similar note, when that server scales up as it's trying to serve millions of hits on your post that went viral, so will your costs. Serving a static site is cheap and can greatly reduce the cost associated with running a web server.

Before we start, you’ll need an AWS account

To work through this guide, you’ll need an AWS account. Luckily, it's free to create an account – you’ll only pay for the services used.

On top of that, AWS provides a generous free tier for some of its services. Some services provide only 12 months of a free tier (like S3) where others are always eligible for the free tier (like Lambda), so make sure to do your homework so you don’t rack up an unexpectedly high bill.

To create your account, head over to the AWS website and then continue on to get started: https://aws.amazon.com/.

Storing your website on S3

To get started, we’re going to begin with a simple HTML file that will serve as our website. This will allow us to focus more on the process of hosting rather than the intricacies of the website itself.

Creating our website file

Begin by creating a new folder called my-static-site. Inside that folder, let's create a new file called index.html and add the following to the file:

<!DOCTYPE html>
<html lang=“en”>
<head>
  <meta charset=“UTF-8”>
  <meta name=“viewport” content=“width=device-width, initial-scale=1.0”>
  <title>My Static Website</title>
</head>
<body>
  <h1>Hello World!</h1>
  <p>This is my static website. ?</p>
</body>
</html>

If you open this file from your computer in your favorite browser, you should now be seeing this.

Hello World! Opening a local webpage

Creating a new bucket

Head on over to your AWS account, log in, and navigate to your S3 console.

Once there, let’s create our bucket by clicking on the blue Create bucket button:

Creating a bucket in AWS S3

The first thing AWS wants us to do is enter a Bucket name. The bucket name must be globally unique, meaning, the name you use can be the only one in the world, so let’s try something like [yourname]-static-website, where I’ll use colbyfayock-static-website.

Naming a bucket in AWS S3

Next, let’s set the Region. This is the geographic location where AWS will host the bucket and your website. You’re probably fine with the default, but if you’d like, you can select the location closest to you if it’s permitted. Since I’m in Virginia, I’m going to stick with my default of US East (N. Virginia).

Setting the region of a bucket in AWS S3

Finally, hit the Create button on the bottom left of the page.

Note: even if you use the [yourname]-static-website pattern, there’s a chance the name will be taken. If it’s taken, AWS will show an error stating “Bucket name already exists,” at which point you’ll want to try a new name of your choosing.

Alternatively, you can hit Next for advanced usage, but for this guide, we’re okay with all of the defaults S3 provides.

If successful, you should now see your bucket in the list on the S3 console dashboard.

New bucket in AWS S3

Uploading your website to the bucket

Let’s navigate to our new bucket by clicking the row of our bucket. You’ll be greeted with a message stating “This bucket is empty. Upload new objects to get started,” so that’s what we’ll do.

Click the Upload button to get started.

Uploading files to AWS S3

You’ll then see a popup that will ask you to upload a file. Click on the Add files button and select your index.html file we created earlier.

Once selected, click the Upload button on the bottom left.

Selecting files to upload in AWS S3

And now your file is uploaded to S3!

Serving your website on S3

If you try to navigate to your index.html file and open it, you’ll notice a big ugly "Access Denied" message.

Access Denied to bucket file

This is because your file doesn’t currently have the permissions and settings necessary to serve the file to the public, so let’s fix that.

Setting up your bucket as a website

Navigate to the Properties tab inside of your bucket, then click Static website hosting.

Setting up an AWS S3 bucket for statice website hosting

Once there, we want to do a few things:

• Note down the Endpoint at the top of the block. We’ll use this to access our site later (you can always find this here again)
• Select the “Use this bucket to host a website” option
• Enter index.html in the Index document field
• Finally hit Save

Configuring an AWS S3 bucket for static website hosting

Setting up your bucket policy and permissions

Next, navigate to the Permissions tab. Here we’ll want to do 2 things: unblock all public access and add a Bucket Policy.

First, on the main page, let’s click Edit to unblock all access.

Configuring an AWS S3 bucket permissions

Then, uncheck the “Block all public access” checkbox and hit Save.

Allowing public access to an AWS S3 bucket

AWS will ask you to confirm these settings, as this may not always be what you want to do with your bucket. But for the purposes of hosting a website, we want the whole world to see, so type in the word “confirm” and hit the Confirm button.

After confirming, click the Bucket policy button and you’ll be taken to a text editor.

In this text box, we’ll want to paste the following snippet. Within this snippet, make sure to replace [your-bucket-name] with the name of your bucket, otherwise you will not be able to save this file.

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::[your-bucket-name]/*”
      ]
    }
  ]
}

This policy states that it’s allowing the public to perform a GetObject request on the S3 resource, which is your S3 bucket.

Setting up a public policy for an AWS S3 bucket

After you add the policy, click the Save button. Your should now see a message stating "This bucket has public access.”

Previewing your new bucket website

If you noted down the Endpoint from your Properties page, you can now visit that address to see your website. The endpoint should look like this:

http://[your-bucket-name].s3-website-[region-id].amazonaws.com

If you didn’t, jump back up a few steps to remind yourself how to find it or look under the Properties tab.

Hello World! Opening an AWS S3 website

Congrats, you're halfway there! ?

Distributing your website on CloudFront

Now that we have our static website being served from a bucket on S3, let’s take it up another level and serve it across the world using CloudFront.

Creating a CloudFront distribution

Navigate to your CloudFront dashboard and click the Create Distribution button.

Creating a new distribution in AWS CloudFront

Next, select Get Started under the Web delivery method.

Getting started with an AWS CloudFront distribution with Web delivery

Here, we’ll enter a few custom parameters to get our distribution set up.

Click into the Origin Domain Name field. Once selected, a dropdown list should appear where you can select the S3 bucket you just created. Go ahead and select your S3 bucket.

Setting the origin domain name in AWS CloudFront to your bucket

While you can customize most of the settings to your liking, for our purposes, we’re going to leave all as their default values except for one.

Scroll down to the Default Root Object field and type index.html.

Setting the Default Root Object for a distribution in AWS CloudFront

After, scroll down to the bottom and click Create Distribution in the bottom right.

Creating an AWS CloudFront distribution

Previewing your new CloudFront distribution

After hitting the Create button, it will take some time for your distribution to be created and set up. You’ll notice on the CloudFront Distributions list page that the Status of your new distribution is In Progress.

AWS CloudFront distribution deployment is In Progress

Once this completes, it will say Deployed. Then you can find your Domain Name in the same row.

AWS CloudFront distribution is Deployed

Using the value in the Domain Name column, open your distribution in your browser and success! You now are viewing your S3 bucket through CloudFront’s distribution network.

Hello World! Opening an AWS CloudFront website

Custom domain names

While most of us will probably want to use a custom domain name with our website, we’re not going to dive too deep into that this guide, as there are many ways to set that up depending on where you purchase your domain name.

However, here are a few things to consider.

HTTPS / SSL Certificate

If you’re creating your CloudFront distribution to use with a custom domain name, you'll most likely want to configure your distribution with an SSL certificate using AWS’s Certificate Manager. Alternatively you can provide your own certificate with tools like Let's Encrypt, but by using ACM, AWS makes it easy to pull in the records for use with your distribution.

Once in ACM, you’ll want to configure the certificate, map what domains and subdomains should match (typically *.domain.com), and then create your certificate to use with your distribution.

To get started, you can check out the AWS guide for requesting a public certificate.

CNAMEs and Aliases

A common approach to setting up a custom domain is to use a CNAME. CloudFront makes this pretty painless, as you’ll add it as a configuration option when you’re configuring your distribution.

To get started with setting up a CNAME in CloudFront, see the AWS guide.

If you’re using Route53 to manage your DNS, you can then set up an A record (alias) to point to your distribution. You can learn more using this guide.

Advanced AWS Usage

For this guide, we walked you through setting up a new static website and app using the AWS console. But whether you want to learn more, improve your deploy efficiency, or want to automate this process, you’ll want to take a it a step further with the AWS CLI or CloudFormation.

While we won’t walk you through how to use these tools here, we’ll get you started with a little bit of an idea of what you’re up against.

AWS CLI

The AWS CLI allows someone to perform AWS operations from the command line. This can be incredibly powerful when you want to script out your resource creation or if you simply prefer to do all of your work from the terminal.

Once set up locally, you’ll be able to perform actions like creating a bucket using the following command:

aws s3api create-bucket —-bucket [your-bucket-name] —-region [bucket-region]

To get started, check out the AWS CLI Github page or the AWS CLI User Guide .

AWS CloudFormation

AWS preaches “infrastructure as code.” It’s the idea that you can spin up your infrastructure using something that’s written in a file, where in this particular case, it would be a CloudFormation template. This allows you to have a repeatable process that will be the same each time you perform the deploy.

CloudFormation allows you to set up a configuration file that will deploy the services and resources of your choosing by pointing to that file with the CLI or by uploading it in the console.

Here’s an example from AWS of what that looks like for a static S3 bucket that could serve as a website.

AWS CloudFront template example

To get started, check out AWS’s CloudFormation example templates or their Get Started guide.

Resources

If you’re interested in getting deeper into the AWS ecosystem, here are a few resources to get started:

• AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course (freeCodeCamp.org)
• Introducing The #AWSCertified Challenge: A Path to Your First AWS Certifications (freeCodeCamp.org)
• 10-Minute Tutorials (AWS)
• A Cloud Guru (Paid courses)
• AWS Case Studies (AWS)

We have released a full course on the JAMstack from Phil Hawksworth on the freeCodeCamp.org YouTube channel. Phil is part of the Developer Experience team at Netlify and is very experienced with the JAMstack.

First, you will learn what the JAMstack is and how it compares to other tech stacks. Then, you see how to use the JAMstack with six different examples, all demonstrating different ways to use the JAMstack. The examples continue to grow in scope throughout the course.

The six examples focus on the following topics:

• Creating a static site
• Changing the DOM with JavaScript
• Introducing a static site generator
• Generating pages from a content API
• Generating localized pages, with geo-IP routing at the CDN
• Client-side rendering targeted API content

At the end of the course, you will learn how start using the JAMstack in your own infrastructure. This will be especially helpful if you already have sites using a different architecture and you want to use the JAMstack next to it.

Watch the course below or on the freeCodeCamp.org YouTube channel (4 hour watch).

• What is this JAMstack?
• That’s not to be confused with serverless
• What makes up the JAMstack?
• So what makes a JAMstack app so great?
• Is my website considered to be on the JAMstack?
• What are some examples of JAMstack?
• What are some tools I can use to build JAMstack sites or apps?

What is this JAMstack?

To start, JAMstack is a software architecture and philosophy that adheres to the following components: Javascript, APIs, and Markup.

If this sounds familiar, it's because it is! That React app that you compile down with Webpack and ultimately serve from S3? Yup, that’s a JAMstack app. That simple HTML file that has no JavaScript and literally doesn’t do anything dynamic? Yup, that’s also a JAMstack app.

Bill and Ted play air guitars

That’s not to be confused with serverless

If you’re coming more from the cloud side of things (think AWS, GCP, Azure), you might be inclined to think of serverless and JAMstack as the same thing. Granted they have similarities in the philosophy of how resources are managed, such as hosting a site on S3. But a JAMstack app is not always going to be a serverless app.

Consider an app hosted in static storage on the cloud provider of your choice. Yes, you might be serving the app in a serverless way, but you might be dealing with an API that utilizes Wordpress or Rails, both of which are certainly not serverless.

Combining these philosophies can go a long way, but they shouldn’t be confused as the same.

What makes up the JAMstack?

Back to the JAMstack: it's typically comprised of 3 components: Javascript, APIs, and Markup. Its history stems from growing the term "static site" into something more meaningful (and marketable). So while ultimately a static site is the end result, it's blown up to include first class tooling for every step of the way.

JAMstack breakdown

While there aren't any specific set of tools that you need to use, or any tools at all beyond simple HTML, there are great examples of what can make up each part of the stack. Let's dive in a little bit to each component.

Javascript

The component that’s probably done the most work to popularize the JAMstack is Javascript. Our favorite browser language allows us to provide all of the dynamic and interactive bits that we might not have if we’re serving plain HTML without it.

This is where a lot of times you’ll see UI frameworks like React, Vue, and newcomers like Svelte come into play.

"A Simple Component" example from reactjs.org

They make building apps simpler and more organized by providing component APIs and tooling that compile down to a simple HTML file (or a bunch of them).

Those HTML files include a group of assets like images, CSS, and the actual JS that ultimately get served to a browser via your favorite CDN (content delivery network).

APIs

Utilizing the strengths of APIs is core to how you make a JAMstack app dynamic. Whether it’s authentication or search, your application will use Javascript to make an HTTP request to another provider which will ultimately enhance the experience in one form or another.

Gatsby coined the phrase "content mesh" that does a pretty good job at describing the possibilities here.

Content Mesh

You don’t necessarily have to reach out to only one host for an API, but you can reach out to as many as you need (but try not to go overboard).

For instance, if you have a headless Wordpress API where you host your blog posts, a Cloudinary account where you store your specialized media, and an Elasticsearch instance that provides your search functionality, they all work together to provide a single experience to the people using your site.

Markup

This is the critical piece. Whether it’s your hand written HTML or the code that compiles down to the HTML, it's the first part you’re serving to the client. This is kind of a de facto piece of any website, but how you serve it is the most important piece.

To be considered a JAMstack app, the HTML needs to be served statically, which basically means not being dynamically rendered from a server.

If you’re piecing a page together and serving it with PHP, it’s probably not a JAMstack app. If you upload and serve a single HTML file from storage that constructs an app with Javascript, it sounds like a JAMstack app.

Static output from Gatsby on AWS S3

But that doesn’t mean we have to always build 100% of the app within the browser. Tools like Gatsby and other static site generators allow us to pull in some or all of our API sources at build time and render the pages out as HTML files.

Think if you have a Wordpress blog, we can pull in all of the posts and ultimately create a new HTML file for each post. That means we’re going to be able to serve a precompiled version of the page directly to the browser which usually equates to a quicker first paint and faster experience for your visitor.

One note about "hosting"

Using the term hosting here can be misleading if you’re new to the concept. Yeah, your site is technically getting hosted somewhere, but it’s not in the traditional sense. You don’t have a server that you’re maintaining where you upload your files to with an FTP client like Cyberduck.

Instead, whether your doing it yourself with S3 or piping it into Netlify (which is actually multi-cloud), your HTML and static assets are getting served from object storage. On the tail end of that you typically have a CDN like Cloudflare which caches those files at locations all over the world making your pages load faster for the people visiting your site.

CDN distribution map

So what makes a JAMstack app so great?

JAMstack apps inherently satisfy most if not all of the 5 pillars of the AWS Well-Architected Framework. These are core concepts that AWS considers to deliver fast, secure, high-performing, resilient, and efficient infrastructure.

AWS Well-Architected

Let’s see how…

Speed

The fact that you’re serving JAMstack apps as static files directly from a CDN (usually) makes it likely your app is going to load super fast. Gone are the days where the server has to spend time building the page before responding; now you serve the page as just plain HTML "as is" or with some type of client side hydration like you’d see with React.

Cost

More often than not, JAMstack sites are going to run cheaper than their server side counterparts. Hosting static assets is cheap and now your page is being served at the same rate.

Scalability

Since you’re serving your files off of static hosting, likely a CDN, that pretty much automatically gives you infinite scalability. Most providers will make this claim, meaning you’ll have no trouble letting any influx of people hitting your site in through the front door.

Maintenance

The foundation of your static site isn’t a server, meaning you don't need to maintain it. Whether it’s Netlify, S3, or any other provider, your static HTML, CSS, and JS are maintained for you headache-free.

Security

Doubling down on the lack of server that you have to personally maintain, you don’t really need to worry as much about locking down ways for people to intrude.

Instead, you'll need to focus mostly on permissions to lock down private content and assure your users that their personal information isn't publicly available.

But this also depends on your APIs

As much as these points strike true for the static aspects of your site, keep in mind you still might depend on some type of API for your client-side experience.

Try to take advantage of these requests at compile time when you can, such as with a static site generator. Otherwise you’ll need to weigh the amount of hits you’re making to a dynamic endpoint and how it impacts all of the points above for your overall experience.

Is my website considered to be on the JAMstack?

We already talked about the 3 components (Javascript, APIs, Markup), but what we didn’t talk about is the fact that you don’t necessarily have to use all 3 of them in order to consider your site worthy of the JAM label.

Wayne's World "we're not worthy"

Really it all boils down to the Markup and how you serve it. Instead of your Rails app rendering your HTML for you, you might host a precompiled React app on S3 that reaches out to Rails via a set of APIs.

But you don’t even need to have APIs. You don’t even need to have Javascript! As long as you’re serving an HTML file without it having to be compiled on a server at request time (aka pre-rendering it), you’ve got yourself a JAMstack site.

What are some examples of JAMstack?

freecodecamp.org

Yes! freecodecamp.org and its learning portal is a JAMstack site built on Gatsby. Even with the complexities of providing an app to take code courses with, freeCodeCamp is able to pull together the power of a static site generator and powerful APIs to bring people around the world the power of learning code.

https://www.freecodecamp.org/

You can see Quincy from freeCodeCamp talk more about this at the 2018 JAMstack_conf:
https://www.youtube.com/watch?v=e5H7CI3yqPY

Note: the News and Forum portals are not currently JAMstack sites.

Impossible Foods

The main website for Impossible Foods is no other than a Gatsby site! Everything from their recipes to their location finder are all compiled through our favorite "blazing fast" static site generator.

https://impossiblefoods.com/

web.dev

Google’s web.dev resource center is built out using the growing 11ty. You can even find the code made open source at: https://github.com/GoogleChrome/web.dev

https://web.dev/

What are some tools I can use to build JAMstack sites or apps?

The good news with all of this buzz is there are a ton of tools currently available and a ton more on the way. They might still be a little rough around the edges, but that’s because this is a brave new world of tooling and that takes some smoothing out to get just right.

Constructing your app

This is the fun part. How are you going to build your app? With Scully in the picture, you can pretty much pick your favorite flavor of UI framework and get off the ground running. Here’s a few popular ones to get started, but by no means is it exhaustive.

• 11ty
• Gatsby
• Hugo
• Nift
• Scully (for you Angular fans)
• And many more…

Need me to pick one? Start with Gatsby and bootstrap with a simple starter.

Serving your app

I like to think of this as the easy part depending on your setup. Tools like Netlify and Zeit make this a breeze to configure by hooking into your Github repo and building anytime a new commit gets pushed, but of course you have options like AWS if you want more control.

• AWS
• Azure
• GCP
• Github Pages
• Netlify
• Surge
• Zeit

Need me to pick one? Start with Netlify and take 5 minutes to deploy that Gatsby site.

Making your app dynamic

Really this can be anything that can be used as an API making requests from the browser. I’m not going to list a bunch of examples per type, but here are a few tools and places you can find some resources.

• Auth0 - Authentication
• Cloudinary - Media management
• Google Analytics - Web traffic analytics
• headlesscms.org - Endless list of headless CMSs
• Sanity - CMS
• Serverless Framework - DIY, easy to deploy serverless resources
• Snipcart - Ecommerce
• Stripe - Payment management
• And a bunch of other resources…
• And a bunch of other CMS choices…
• And some general info and tools...

And how about general resources to learn?

You can find a lot of resources to get up and running quickly in the JAMstack world.

• How to host and deploy a static website or JAMstack app to AWS S3 and CloudFront from me on freeCodeCamp
• A Step-by-Step Guide: Gatsby on Netlify from Netlify
• Build your own Blog from Scratch using Eleventy from filament group
• How to Host your Static Website with AWS - A Beginner's Guide from freeCodeCamp
• Hugo Tutorial: How to Build & Host a (Very Fast) Static E-Commerce Site from SnipCart
• How to Build Authenticated Serverless JAMstack Apps with Gatsby and Netlify from freeCodeCamp

Expect to see more

Similar to its serverless counterpart, the days of JAMstack are young. As time goes on, we’ll be seeing the tooling mature and expand providing new exciting ways for us to quickly build fast sites that anyone can use.

Join in the conversation on Twitter and let me know what your favorite part of building a JAMstack site is!

Missing something?

Missing your favorite JAMstack tool or an awesome example? Ping me on Twitter!

Whether you're new, seasoned, or specialized in one end of the stack, there's a lot to digest here. Feel free to dive in from the top or bounce around to where you need the most support.

• First off, what really makes a developer full stack?
• Before we dive in, let’s talk about that focus
• So where do we start?
• Front End
• Back End
• DevOps and the cloud
• What about design?
• Other things if you're just getting started
• Other things if you're looking for more

First off, what really makes a developer full stack?

It’s fun and buzzy to say any front end developer is a full stack developer, but being able to deploy a website to Netlify doesn’t make you full stack.

This isn’t meant to be discouraging – just realistically, only having that experience won’t hold up well to that job title in your next interview. While you’re technically creating and deploying your work from start to finish, Netlify, Zeit, and other providers give you the power to do this with their magical tools that take the majority of the stack operations work out of the equation.

That’s not to take away from what we’re all able to accomplish now as front end devs. The growing movement to compile and deploy static websites has just made this process simpler on the later half of the stack with benefits across the board.

Additionally, with the flexibility of tooling options like being able to run JS on a server, our skillsets are able to transfer to more use cases than ever before.

Where we came from

The web development landscape has been changing rapidly. Wordpress has been king CMS for a little while now, representing over a third of websites who use a CMS and helping PHP gain popularity. But others worked off of homegrown solutions.

https://trends.builtwith.com/cms

These represented a more traditional web stack like LAMP. In these cases, you had web servers usually running some kind of content management system and a server side language (like PHP) that would interface with the databases and produce the code that would ultimately be delivered to the browser.

On top of that, you might have Javascript making some interactive features with CSS managing the display of the page. Now in some instances, having a managed Wordpress server is all you need for certain web hosts. But other larger sites would require another team to manage those services and the deploy pipeline for getting the code out to production.

Where we are and where we’re going

While Wordpress isn’t going anywhere, the serverless and JAMstack architectures are building momentum. For those unfamiliar, the idea isn’t that there are literally no servers, but it’s more about using servers that are managed for you in the cloud.

Services like AWS Lambda let you build a “function” that processes simple input and output. Attach that to API Gateway and you immediately have an endpoint you can interface with without ever having to actually manage a server.

Others like S3 let you dump HTML, CSS, JS, images, and whatever other static assets into storage and serve the site directly from it. Nothing gets processed on the server, you’re simply serving the static files to the client.

The brilliant part about this is there’s a lot less overhead and it's typically a whole heck of a lot cheaper. Many cases, you’ll also get a huge performance boost, where serving a site from s3 will require less processing to get that first response to the browser, which can directly equate to improved user experience.

Thumbs up to a good user experience!

This isn’t to push you to the JAMstack, but to show that the full stack paradigm is shifting and it’s something worth looking at. There still is a traditional sense of the difference in work, but it’s becoming a bit different.

DevOps teams now manage cloud resources and deploys. Backend developers now build APIs and code that interfaces with services using tools like lambda functions. And front end developers primarily work in Javascript building React or Vue apps that reach out to the services your backend developers created. Arguably, this might or might not include things like CSS, but that’s another can of worms about what title that work “officially” falls under (spoiler: depends on the team).

While there is still a split sense of duties, the line is blurring and makes it more manageable to spread your focus.

Before we dive in, let’s talk about that focus

It can be pretty tempting to want to dive right in and cover the full spectrum of a full stack developer, but there’s something to be said about focus. This is the basis of the expression “jack of all trades, master of none,” where you try to learn a little bit of each part of the full stack and never really master anything.

This can be dangerous when starting off trying to build your strengths as a new developer. So try to evaluate what type of learner you are and lend your focus where it matters. If you’re struggling with a spread out curriculum, that might not necessarily help get you the experience you need to land that first job or that dream job you’re reaching for.

A novel approach, for example, could be having an individual focus, but building the full stack skills around that strength. This might be a front end developer who can deploy their own web apps and continuing to build on that fundamental knowledge.

On top of that, part of being a full stack developer isn't necessarily being able to say that you know x, y, and z languages. Understanding code and software design concepts as well as being able to tackle any challenge at hand, stack aside, is what makes a great developer.

The bottom line, try to figure out what's best for you and don't let your high ambition get in the way of mastering your journey.

Mr. Miyagi approves

So where do we start?

For the purposes of this article, we’re going to keep with the traditional breakpoints of what break up the stack (front end, back end, etc.). Though some people say it's not really a thing anymore, realistically, there are tons of jobs for full stack developers and day to day, they refer to the traditional breakpoints. "Full stack developer" definitely isn't going anywhere.

As far as the stack goes, we’re going to lean on the serverless / JAMstack architectures, as that’s just going to keep growing. And if you learn them, it will only make you more marketable with the number of jobs popping up around it.

Boomshakalaka!

As you'll notice below, this isn't meant to be all encompassing with every type of database and every type of rendering solution. A strong developer should be able to be flexible with their tooling, reaching to understand the concepts of their work rather than being single minded and only being able to be productive in one framework.

While you may be working in React and comfortable with it in your current job (that's okay!), your next job could be heavy on Vue or "surprise!" your team lead wants to rewrite the app in Svelte. Try to understand why you're using a UI framework in the first place and how it's helping you solve the problem at hand.

Now let's get into it...

Front End

The front end of a website or application is typically the UI that the person using your service interacts with. The biggest language player in the game is Javascript, where you’ll typically lean on UI libraries such as React or Vue to manage the components of your project.

Using these UI frameworks will allow you to create “components”, essentially blocks of code, that will end up producing HTML with the ability to create interactions and dynamic states right along with your code. This becomes really powerful, and while there might be a little curve to start, it becomes pretty delightful to work with once you get the hang of it.

Whether new to the field or well experienced, you might eventually run into jQuery. While it has it’s merits and has served the community well, Javascript’s native features have really grown and created less demand for the functionality jQuery was able to provide. Now devs lean on the UI frameworks and native Javascript instead.

So it’s good to understand what jQuery is, but I don’t recommend taking the time to learn it at this point. The good thing is, if you land a job that uses it, you can write native Javascript right along with jQuery, so learning vanilla Javascript itself is the right answer.

So what should I learn?

If you’re truly a beginner, take the time to learn basic HTML and CSS. It might not be as fun and attractive as digging right into Javascript, but building upon the fundamentals of what makes the web will be key to starting off on the right foot.

Next, learn Javascript. It will remain king for the foreseeable future. Javascript will provide the basis of any framework or library that you build upon, so getting to understand how the bits and pieces of the language itself works will help propel you through your journey of learning the front end side of things.

It will also make your life easier when you’re trying to understand some of the complexities of different patterns and the concepts behind the frameworks you’ll use.

Speaking of frameworks, React and Vue are probably the best candidates given their popularity. React is the most popular out of the bunch and is just going to keep growing. Its team is constantly working to mature the framework and produce APIs that will help build modern, fast web apps.

_2019 State of JS Frameworks_

Getting started with Create React App or Gatsby will even help you easily spin up a React app and immediately get into a position where you can tinker around in the code.

While there would be benefits to call out CSS preprocessors and tools like Sass, there are a ton of solutions now for CSS including CSS-in-JS.

While putting CSS inside of JS has some pros and cons, it isn't necessarily worth pointing out what to use as a particular direction, as it's really going to be team dependent.

Understanding the basics and power of CSS and how to use it in it's vanilla form will help prepare you for utilizing it no matter the framework.

Resources

• freecodecamp.org Responsive Web Design Certification https://www.freecodecamp.org/learn
• “Put Down the Javascript: Learn HTML & CSS first“ https://www.freecodecamp.org/news/put-down-the-javascript-learn-html-css/
• MDN Intro to Javascript https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript
• Just Javascript email course https://justjavascript.com/
• JSRobot Learning Game https://lab.reaal.me/jsrobot/
• reactjs.org Intro to React https://reactjs.org/tutorial/tutorial.html
• gatsbyjs.org Tutorials https://www.gatsbyjs.org/tutorial/

Back End

In the JAMstack world, the back end will generally refer to the APIs that our front ends use to create dynamic experiences by interacting with endpoints from the client (like those in CRUD APIs). Being able to make those requests from the client will remove the need to have to do any of that processing before the page is served to the browser.

Though you shouldn’t feel like you can only ever code in one language, being able to write in Javascript gives a nice advantage here, as you can grow into the fundamentals of working with the back end side of things with a familiar language (or vice versa with the front end).

NodeJS is a common runtime that you’ll find in most cloud environments as an option and will give you a similar experience to what you’d expect in a browser. The main difference is that you won’t have access to certain browser APIs nor will there be a window object and the APIs associated with it.

That said, Python is also another popular language and is growing, especially given its popularity in the data science and engineering community. PHP and Ruby, while both are valid and will give you options in the job market, don’t seem to be as popular and not as much on an overall upward trend as Javascript and Python.

_Popular languages on Github_

With the language of your choice, your best bet will be learning how to create cloud services that your applications can interface with.

Creating a simple lambda that you can play around with, whether in AWS, Netlify, or any other cloud provider, will give you a good experience as to what you might expect when working in the field.

And even if you may not develop directly in a lambda in the job you find, you’ll be able to start getting familiar with concepts that are fundamental to working with the back end. And you'll ultimately use those functions to connect with other services and databases to create your own dynamic services.

So what should I learn?

If you’re already working on learning Javascript from the front end side of things, keep going by using Javascript for your backend. Spin up a lambda using Netlify functions, where you just need to focus on the code and Netlify takes care of the rest (like actually getting your function built and deployed).

With your language of choice and first function, try to start working with other services within your code to get experience working with 3rd party APIs.

Maybe build an endpoint that can send out a tweet using the Twitter API (but don’t abuse it). Learn how to create a database and set up your function to interface with it in a CRUD pattern, which will give you a more realistic use case for how a typical app might interact with a backend.

Your goal here should be creating services that your front end will interact with via an endpoint to perform operations for the person using your app. The good news is given the momentum of the cloud, you’ll have a ton of options, and free options or tiers, to start playing around with.

Resources

• “Super simple start to serverless” https://kentcdodds.com/blog/super-simple-start-to-serverless
• “Building Serverless CRUD apps with Netlify Functions & FaunaDB“ https://www.netlify.com/blog/2018/07/09/building-serverless-crud-apps-with-netlify-functions-faunadb/

DevOps and the cloud

DevOps stems from the need to be able to create solutions that smooth out and speed up the process of getting code from the people writing it to a deployed state.

This work can range from a lot of responsibilities to a few, whether it’s writing bash scripts for a custom solution or writing a CloudFormation template that creates all of the resources needed for an app to run.

You’ll typically find this included as part of a larger orchestration of CI/CD workflows which automate the build and deploy process.

CI / CD Pipeline

And this is constantly changing! Given the serverless boom, the serverless framework popped up which manages a lot of this for you in an easier way, which even lead AWS to create their own solution SAM. Tools like Jenkins have been around for a bit for the CI/CD part of things, but now you’re seeing Github, Gitlab, and other source control providers provide their own solutions and tools like CircleCI that hook right into your project.

It’s also not perfect yet – writing CloudFormation templates is daunting. Writing automation scripts also isn’t the most fun, though it’s super rewarding when it works!

But this is getting better, which is where products like Netlify and Zeit fit in. While they root more from the static hosting side of things, where you compile your app and dump it into storage, their offerings are growing, like Netlify’s Functions that are really just AWS Lambdas that are easier to set up and deploy to a fully functioning endpoint (it’s seriously super easy).

So what should I learn?

If this is your first time setting this kind of thing up, start with Netlify. Set up a React app or even just a simple HTML file in a Github repository, connect it to a new Netlify account, and watch it deploy.

Easy spinup with Netlify

From there, or if you have a little experience already, start getting curious about what’s going on behind the scenes. Netlify is likely taking your code, running the commands you set up (like yarn build) in a virtual environment, dumping the files built into storage like S3, and putting a CDN in front of it like CloudFront to serve from an endpoint.

First try doing that manually from your computer using the AWS console and their CLI, then write a script to automate the whole process integrating with Circle CI into your Github project instead of Netlify to get it actually deployed to AWS.

Taking that up a notch will include spinning up services that your back end might interface with. Do you have a database that your services use? You can automate spinning up that database using CloudFormation or bash scripts.

Treating your infrastructure as code with disposable, easily recreatable resources will help you and your projects become more flexible and have a better ability to spin back up in the event of failure.

And this all goes for any cloud or CI / CD provider, not just AWS and Circle CI. Pick your favorite cloud and workflow tool and run with it. The point is, start looking at your project’s needs and dig into what’s actually happening in the automated parts of the stack. This will help you learn more and become more resourceful for your project’s needs.

Resources

• “A Step-by-Step Guide: Deploying on Netlify” https://www.netlify.com/blog/2016/09/29/a-step-by-step-guide-deploying-on-netlify/
• “Setting up a Static Website” https://docs.aws.amazon.com/AmazonS3/latest/dev/HostingWebsiteOnS3Setup.html
• “AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course" https://www.freecodecamp.org/news/aws-certified-cloud-practitioner-training-2019-free-video-course/
• See Javascript resources in Front End above

What about design?

Yes, you should understand design basics. No, you don’t need to be a designer.

There are many aspects about design that will accelerate your abilities as a developer. While we all know the visual and UX designers produce magic, having a basic understanding can prevent your application from becoming a huge disappointment.

Fictional Pied Piper's app tanked because of a bad user experience

Everyone in the development process is working towards a goal that impacts an end user in one way or another. Being able to understand what needs your work is trying to solve and how that impacts users will help the team as a whole develop a more comprehensive end solution.

Consider a back end developer creating an API to allow someone to manage users in an app. The requirements of the API are pretty lean and only include the user’s name. Providing that as a single “name” field instead of “first” and “last” might not be the most intuitive solution for most. But it could be an oversight that complicates how the front end developer exposes that in the UI, which would make it a pain for the developer to display or could make it confusing for the end user to consume.

On top of all of that, design can directly impact conversion. If you're building in the ecommerce space, having a button that doesn’t look like a button can prevent people from adding a product to their cart. This, of course, will prevent a purchase, which is lost revenue. Understanding how to humanize the UI even in a basic sense can literally make your project more money or simply help someone use it more easily.

And more importantly, you want your site to be accessible. Many people have different needs, whether they can't see colors the same or can't hear the sounds your app produces, you want to recognize other's needs and try to design in a way that will make your app usable by everyone.

So what should I learn?

While I don’t expect you to take a whole course for it, try to be cognizant and curious. And maybe next time don’t skip that design article you saw pop up on the freeCodeCamp twitter.

When creating solutions, try to imagine how your work will be used. What will the other developers on your team need from your API? What will the people using your app need from your interface?

You can also try to get inspiration from what others are doing in your space. How would you expect an app to look when providing similar functionality? This isn’t license to copy or steal, but you should understand the needs their solution is solving. Consider why their Add to Cart button is so huge, why they’re giving users the ability to zoom in on a product photo, or how you can make a table design slightly more usable.

"table" product design on Dribbble

As for accessibility, try to learn the basics. There's a growing amount of resources available to help you understand the needs of others. Try to understand what disabilities there are and how they might affect use of your app. Maybe look at a few common patterns about how to address those concerns.

More often than not, it's not too hard to incorporate, and if you get in the habit of doing it from the start, you won't even think about it the next time you build an app.

Resources

• Design for Developers https://thoughtbot.com/upcase/design-for-developers
• Hack Design https://hackdesign.org
• Design for Hackers https://designforhackers.com/
• Intro to Web Accessibility https://webaim.org/intro/

Other things if you're just getting started

A lot of this article assumes you have some of the basics down such as understanding what git and source control is or simply having your code editor set up. If you're truly just getting started, you're going to want to at least have a simple understanding of these concepts, as it'll quickly grow more challenging without them.

There's also something to be said about learning how to use your terminal. It can be overwhelming not to use a GUI if you're new, but once you get moving, you'll quickly find out you'll be more productive by using a terminal and a lot of projects require terminal use anyways.

So what should I learn?

First things first, get your code editor set up. Visual Studio Code is all the rage right now, but there are others that will serve you well depending on your preferences like Atom or Sublime Text. You'll even find cloud based IDEs like Repl.it or you can just get started with a lower barrier of entry by playing around in CodePen or JSFiddle.

Visual Studio Code is so hot right now

Either way, once you're ready to get coding, you want to understand what source control is, where git is the biggest player right now. Git is a powerful tool that lets you track changes to code and become more productive collaborating with other developers.

You'll want to get familiar with some of the basic commands of git like adding new changes as well as what branches are and how to use them. Git is a huge world, you don't need to master it right away, you'll quickly learn there's an endless amount of new things to learn on your journey to mastering your git fu.

For a lot of tools you'll use, there are GUIs available like GitKraken, but you'll still be a bit limited with what you can do. Learning your way around the default terminals on your machine or downloading other options like iterm2 (my preference) or Xterm.js will be your best bet. Bonus: you'll feel like a movie hacker every time you use it (or is that just me?).

Hugh Jackman hacking in Swordfish

Resources

• Getting Started with Visual Studio Code https://www.codecademy.com/articles/visual-studio-code
• Git resources from Github https://try.github.io/
• Learn git by branching game https://learngitbranching.js.org/
• Intro to the Mac Command Line https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line

Other things if you're looking for more

There's so much more you can quickly go down a rabbit hole with. Remember not to spread your focus and try not to overwhelm yourself. But if you're feeling pretty good about where you are, there are some other concepts that will only help as you tackle challenges in the real world.

Testing and the different methodologies

Writing code is one thing, but being able to set up effective tests will help harden your code and prevent bugs from getting out. You don't want to waste your future time or even cost your product money when the site goes down. Learning how to write tests and the different approaches is important to solidifying your code.

Browser tools like Chrome DevTools

One of the most powerful tools you can have when debugging, in my opinion, is being able to debug your application in the browser.

Whether it's looking at how the DOM is being rendered, playing with the CSS, or debugging your network requests, you'll learn quickly how to save time and more easily identify where the bug is coming from.

HTTP and how to debug requests in the network panel

Given the web is based on the internet, your application will ultimately be making requests to other servers. When this happens, understanding the request chokepoints or simply how a request is being made can help you understand why your application seems laggy or why your save button isn't working.

Having a basic understanding of how requests works and how to visualize them for debugging will go a long way in your journey.

Open Source Software and package managers

This one's not as much of a skill or tool to learn as much as it is a way that software is distributed. As you start building code solutions, you'll find out that a lot of us lean on open source packages. Most of the time it's through npm if you're writing Javascript, which helps us become more productive not having to reinvent the wheel each time.

Spend some time getting to understand the open source concept and even consider giving back by contributing to your favorite project. Lending a hand is usually super appreciated, will help you gain experience, and you might even be able to score some free swag on your first approved pull request! Just be respectful out there, there's also a real person on the other side of the request.

What else?

This list can go on forever as there's so much to the world of coding. What else do you think is important in one's journey to become a development master? Send me a tweet or DM if you think I'm missing something important!

You're on fire! Pulling it all together

Given all of the experience you’ll have accumulated with the above, you should be in a position to be able to create an entire app from start to finish by yourself. Do you understand the power that you have?

Thanos squeezing the gauntlet

This is where the fun starts. Try to create a new app – doesn’t matter what it is, just build something. The best thing you can do for learning is to gain experience by doing. Doesn't matter whether it’s one of the million todo tutorials you’ll find or by teaching yourself to code by building one of the largest social networks like the creator of Instagram.

From here, you should be able to create:

• A web app front end that runs in the browser
• Backend services that your web app can make requests to via endpoints
• Write a script to plug into a CI / CD tool to automate your build and deploy process
• Bonus: making good decisions about how your interface looks so people can actually use it!

Go forth and build! Share with us your development journey on Twitter using hashtag #codejourney. We'd love to hear more about where you've been and what you've built or where you're going and what you want to build.

When interacting with a backend, a JAMstack app can do everything a mobile app can do, without the tyranny of the app store. This is a fundamental insight that goes as deep as the fight for a more open, secure, decoupled, faster web.

Static site generators (SSGs) are traditionally used to generate markup HTML for static sites, and even e-commerce sites, but the modern generation of JavaScript SSGs are enabling full-blown, blazing fast web apps. Gatsby uses JavaScript to rehydrate Markup into a fully dynamic React app - which means you can use APIs to do all sorts of dynamic functionality!

Let's see how we can incrementally add functionality to a Gatsby static site with Netlify Functions, and then add authentication with Netlify Identity to create a proper Gatsby app. We'll gradually build up to a full working demo with:

• ??Dynamic Clientside Pages in Gatsby
• ?Serverless Functions (with Netlify Dev)
• ??‍♂️Hide API Secrets from being exposed to Frontend
• ?Authentication (with Netlify Identity)
• ?Protected Routes
• ?Authenticated Serverless Functions (why not!)
• ?External Provider login with GitHub, Bitbucket, Google, etc.

Not Your Parent's Static Site Generator

Why would you use something like Gatsby over Jekyll or Hugo or one of the hundreds of Static Site Generators out there? There are many reasons, but one of the unique selling points is how Gatsby helps you build "Static Progressive Web Apps" with React.

Gatsby's ability to rehydrate (what a delicious word!) the DOM means you can do incredibly dynamic things with JavaScript and React that would be much harder with legacy SSG's.

Let's say you have a typical static Gatsby site, like gatsby-starter-default. You can npm run build it, and it spits out a bunch of HTML files. Great! I can host that for free!

Now imagine your client comes to you and asks you to add some custom logic that needs to be executed on the server:

• Maybe you have third party API secrets you don't want to expose to your user.
• Maybe you need a serverside proxy to get around CORS issues.
• Maybe you need to ping a database to check your inventory.

Oh no! Now you have to rewrite everything and move to a Digital Ocean droplet!

I'm kidding. No, you don't have to rewrite everything.

The beauty of serverless functions is that it is incrementally adoptable - your site grows with your needs - and with JavaScript you can rerender entire sections of your site based on live API data. Of course, the more you do this, the more resource intensive (in terms of bandwidth and computation) it can be, so there is a performance tradeoff. Your site should be as dynamic as you need it to be, but no more. Gatsby is perfect for this.

Using Netlify Dev to add Serverless Functions

Netlify Functions are a great low configuration solution for adding serverless functionality to your Gatsby site.

We'll assume you have a Gatsby site ready to go already, preferably linked to a Git remote like GitHub. If you don't have one, fork and download gatsby-starter-default. Let's walk through the steps to add Netlify Functions:

1. Install Netlify CLI and login:

npm i -g netlify-cli
netlify login # to link your free Netlify account

Pretty straightforward.

2. Create your Netlify instance for your Gatsby site:

netlify init

You will be prompted for a "build command", which for Gatsby is yarn build, and a "publish directory", which for Gatsby is public. You can also save this in a netlify.toml config file, or the CLI will create it for you:

[build]
  command = "yarn build"
  functions = "functions"
  publish = "public"

As you can see in the above example, We'll also specify where we'll save our functions to the creatively named functions folder.

3. Create your first Netlify Function: Netlify CLI has a set of templates available to help you get started writing serverless functions. Just run:

netlify functions:create # ntl functions:create also works

You'll be presented with an autocomplete list. We'll pick the token-hider example for now. Once you select it, the CLI will copy out the necessary files, and install the necessary axios dependencies.

Notice that token-hider.js includes this line:

const { API_SECRET = "shiba" } = process.env

This is meant to simulate API secrets that you don't want to expose to the frontend. You can set these as build environment variables on your site's Netlify Dashboard. You can name them whatever you like, and for the purposes of our demo we've provided a default, but of course feel free to modify this code however you like. It's Just JavaScript™!

4. Make sure function dependencies are installed with netlify-lambda (Optional but Recommended)

Notice that your function comes with its own package.json and node_modules. This means each function can have their own independently managed dependencies, but you also need to make sure these dependencies are installed when you deploy or when someone else clones your repo. You can either check them into git (ugh!), or write a bash script to do this installation. But don't worry, there's a simple utility to automate this:

yarn add -D netlify-lambda

And add a postinstall script in package.json (this isn't Netlify specific, it is part of how npm works):

  "scripts": {
    "postinstall": "netlify-lambda install"
  },

5. Fire up Gatsby and Functions with Netlify Dev

Netlify Dev is the local proxy server embedded in the CLI that we will use to develop our Functions alongside our Gatsby app. You can start it like so:

netlify dev # or ntl dev

Your Gatsby app will now be accessible at http://localhost:8888 and your function will be accessible at http://localhost:8888/.netlify/function/token-hider. Check it out in your browser!

How are both the Gatsby dev server and the Netlify Functions server both available on the same local port? How come the API_SECRET you set on the Netlify side is available in local development? The rough mental image you should have looks something like this:

You can hit your Netlify Function from anywhere in your Gatsby app! For example, in any event handler or lifecycle method, insert:

fetch("/.netlify/functions/token-hider")
  .then(response => response.json())
  .then(console.log)

and watch a list of dog images pop up in your console. If you are new to React, I highly recommend reading through the React docs to understand where and how to insert event handlers so you can, for example, respond to a button click.

Adding Authentication

So, yes, your site can now be more dynamic than any static site: It can hit any database or API. You can hide API tokens from prying eyes. It runs rings around CORS (by the way, you can also use Netlify Redirects for that). But its not an app app. Yet!

The key thing about web apps (and, let's face it, the key thing users really pay for) is they all have some concept of user, and that brings with it all manner of complication from security to state management to role-based access control. Entire routes need to be guarded by authentication, and sensitive content shielded from Gatsby's static generation. Sometimes there are things you -don't- want Google's spiders to see!

It's a different tier of concern, which makes it hard to write about in the same article as a typical Gatsby tutorial. But we're here to make apps, so let's bring it on!

Adding Netlify Identity and Authenticated Pages to Gatsby

1. Enable Netlify Identity: Netlify Identity doesn't come enabled by default. You'll have to head to your site admin (eg https://app.netlify.com/sites/YOUR_AWESOME_SITE/identity) to turn it on. Read the docs for further info on what you can do, for example add Facebook or Google social sign-on!
2. Install dependencies: npm install gatsby-plugin-netlify-identity react-netlify-identity-widget @reach/dialog @reach/tabs @reach/visually-hidden gatsby-plugin-create-client-paths
3. Configure Gatsby: for dynamic-ness!

// gatsby-config.js
module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-create-client-paths`,
      options: { prefixes: [`/app/*`] },
    },
    {
      resolve: `gatsby-plugin-netlify-identity`,
      options: {
        url: "https://YOUR_AWESOME_SITE_INSTANCE_HERE.netlify.com",
      },
    },
  ],
}

This sets up everything under the /app route to be dynamic on the clientside, which means you can put it behind an authentication wall.

4. Add the login widget: netlify-identity-widget is a framework-agnostic overlay that ships with a nice signup/login UI. However it is a 60kb package, so there is a 6kb alternative that simply assumes you're using React: react-netlify-identity-widget.

The widget is implemented as an accessible modal with @reach/dialog, so you need to put it somewhere in your app:

// src/app/login.js
import React from "react"
import { navigate } from "gatsby"

import { IdentityModal } from "react-netlify-identity-widget"
import "react-netlify-identity-widget/styles.css" // delete if you want to bring your own CSS

export default function Login() {
  const [dialog, setDialog] = React.useState(false)
  return (
    <div>
      <h1>Log in</h1>
      <button onClick={() => setDialog(true)}>log in</button>
      <IdentityModal
        showDialog={dialog}
        onCloseDialog={() => setDialog(false)}
        onLogin={user => navigate("/app/profile")}
        onSignup={user => navigate("/app/profile")}
      />
    </div>
  )
}

react-netlify-identity-widget uses React Context, so it normally requires adding a Provider, but gatsby-plugin-netlify-identity already did that for you (that's its whole purpose!).

As you might expect, you can use that Context in the rest of your app. react-netlify-identity-widget exports a Custom Consumer Hook called useIdentityContext, which helps do some runtime checks and makes TypeScript typing easier by removing an undefined check.

useIdentityContext returns an identity object, and you can see the plethora of data and methods it exposes to you on the docs. Let's use them to implement a NavBar component!

// src/app/components/NavBar.js
import React from "react"
import { Link, navigate } from "gatsby"
import { useIdentityContext } from "react-netlify-identity-widget"

export default function NavBar() {
  const { user, isLoggedIn, logoutUser } = useIdentityContext()
  let message = isLoggedIn
    ? `Hello, ${user.user_metadata && user.user_metadata.full_name}`
    : "You are not logged in"
  const handleClick = async event => {
    event.preventDefault()
    await logoutUser()
    navigate(`/app/login`)
  }
  return (
    <div>
      <span>{message}</span>
      <nav>
        <span>Navigate the app: </span>
        <Link to="/app/">Main</Link>
        <Link to="/app/profile">Profile</Link>
        {isLoggedIn ? (<a href="/" onClick={handleClick}>Logout</a>) : (<Link to="/app/login">Login</Link>)}
      </nav>
    </div>
  )
}

5. Write the rest of your app: Because of our configuration in gatsby-plugin-create-client-paths, any sub paths in src/pages/app will be exempt from Gatsby static generation. To keep the dividing line between app and site crystal clear, I like to have all my dynamic Gatsby code in a dedicated app folder. This means you can use @reach/router with react-netlify-identity-widget to write a standard dynamic React app with private, authenticated routes. Here's some sample code to give you an idea of how to hook them up:

// src/app/app.js
import React from "react"
import { Router } from "@reach/router"
import Layout from "../components/layout"
import NavBar from "./components/NavBar"
import Profile from "./profile"
import Main from "./main"
import Login from "./login"
import { useIdentityContext } from "react-netlify-identity-widget"
import { navigate } from "gatsby"

function PrivateRoute(props) {
  const { isLoggedIn } = useIdentityContext()
  const { component: Component, location, ...rest } = props

  React.useEffect(
    () => {
      if (!isLoggedIn && location.pathname !== `/app/login`) {
        // If the user is not logged in, redirect to the login page.
        navigate(`/app/login`)
      }
    },
    [isLoggedIn, location]
  )
  return isLoggedIn ? <Component {...rest} /> : null
}
function PublicRoute(props) {
  return <div>{props.children}</div>
}

export default function App() {
  return (
    <Layout>
      <NavBar />
      <Router>
        <PrivateRoute path="/app/profile" component={Profile} />
        <PublicRoute path="/app">
          <PrivateRoute path="/" component={Main} />
          <Login path="/login" />
        </PublicRoute>
      </Router>
    </Layout>
  )
}

Phew that was a lot! but you should have a solid starting point for your app now :)

Bonus points: Authenticated Netlify Functions ?

Just like every magic act has a pledge, a turn, and a prestige, I have one last tidbit for you. Nothing on the client-side is safe. Although you can send along Netlify Identity user ID's to your Netlify Function endpoints for authenticated access from your Gatsby App (for example in the body of a POST request), you'll never be truly sure if that flow is secure either from malicious users or snooping.

The best way to do authenticated actions inside serverless functions is to do it from inside the context of the function itself. Fortunately, Netlify Identity and Functions work seamlessly together. All you have to do is to send along the user's JWT when hitting your endpoint:

// in your gatsby app
const { user } = useIdentityContext()
// in an event handler
fetch("/.netlify/functions/auth-hello", {
  headers: {
    Accept: "application/json",
    "Content-Type": "application/json",
    Authorization: "Bearer " + user.token.access_token, // like this
  },
}).then(/* etc */)

If even this is too much boilerplate, you can even use the fetch wrapper that ships with the identity object:

// in your gatsby app
const { authedFetch } = useIdentityContext()
// in an event handler
authedFetch("/.netlify/functions/auth-hello").then(/* etc */)

And then inside your Netlify function, you can now check the user object or pass it on to your end API or database:

module.exports = { handler }
async function handler(event, context) {
  if (context.clientContext) {
    const { user } = context.clientContext
    // you can get actual user metadata you can use!
    return {
      statusCode: 200,
      body: JSON.stringify({
        msg: "super secret info only available to authenticated users",
        user,
      })
    }
  } else {
    return {
      statusCode: 401,
      body: JSON.stringify({
        msg:
          "Error: No authentication detected! Note that netlify-lambda doesn't locally emulate Netlify Identity.",
      }),
    }
  }
}

Gatsby + Netlify - Perfect for your next Hackathon

As you can see, it's a few steps to turn your static Gatsby sites into dynamic, authenticated, fully serverless apps with Netlify's free tools. This makes Gatsby a perfect tool for your next app. If you're at a hackathon, short on time, or just like to see a full working demo, check any of the following links.

• Code: https://github.com/sw-yx/jamstack-hackathon-starter
• Starter: https://www.gatsbyjs.org/starters/jamstack-hackathon-starter
• Live Demo: https://jamstack-hackathon-starter.netlify.com/

Traditionally, forms are managed with the help of a server (also known as server side), but this is more efficient when you’re processing the data from the form, maybe a user registration form where the form data is validated, authenticated and saved in a database.

When you’re building a simple form where you’re only receiving data from the user and not processing (i.e contact form) the goal is to get the data from the form and send to your company support email (e.g info@…, support@…)

Using a server here is not ideal and is only an overkill, a very common way of doing this is via PHPMailer ( The classic email sending library for PHP). PHPMailer is used with PHP and requires a lot of boring server configurations. What if you’re just building a static site? There should be an easier way of doing this client side right?

In this article, I’ll introduce you to two methods of handling form data client side in static sites. There are other methods but I’ve used these two and considered them to be the best and easiest (no hard feelings :) ).

NO hectic configurations, NO servers, NO serious stuff, just build your form, do some little tweaks, the user submits and bingo it heads straight to your designated email. :)

STARTER FORM

For the purpose of this article, I’ve built a basic form with HTML5 and Bootstrap 4, you can fork it from the Codepen below.

Currently, this form uses none of the methods we’ll talk about, at the end of the article, I’ll provide the full code for both methods, you can then update the form and test. I’ve added a little validation, don’t worry about that

Now, let’s get started!!

METHOD ONE

Formspree provides functional HTML forms via their platform with no PHP or JavaScript. Send your form to their URL and it’ll be forwarded to your email. No PHP, Javascript or sign up required — perfect for static sites!

Wait!, wait!!, wait!!! it’s Open Sourced too

FORM HANDLING WITH FORMSPREE

• Build your form, we’ve done that already

(Follow the next step and update this form to use this method)

<form action="https://formspree.io/you@email.com" method="POST">
    <input type="hidden" name="_subject" value="Bolaji's Form">                 
    <input type="hidden" name="_next" value="/thanks.html" >
    <input type="text" name="name">
    <input type="email" name="_replyto">
    <input type="text" name="phone">
    <input type="submit" value="Send">
</form>

Now let’s go over the new stuff added above.

• We changed the form’s action-attribute to [https://formspree.io/you@email.com](https://formspree.io/you@email.com) [replace your@email.com with your own email.] This is simply sending your form data to formspree then to your email. Formspree is acting as a third party here.

• I’ve added some name attributes to the input fields. This is just configuring each field so we can grab the data and send to formspree.

— For Email address, I added a _replyto attribute (This just mean, you’ll be able to quickly reply to the user who originally submitted via email)

— I’ve added a _subject attribute. This value is used for the email’s subject so that you can quickly reply to submissions without having to edit the subject line each time.

— I’ve added a _next attribute. By default, after submitting a form the user is shown the Formspree “Thank You” page. You can provide an alternative URL for that page like so: <input type=”hidden” name=”_next” value=”/thanks.html" />

formspree default success page

custom success page I built for a client.

• We added a value attribute to the send button [value=”Send”]

This is our Thanos, one snap at this button and your form is erased and its data sent to your email.

That’s all to using formspree :) Although there are other configuration settings for several other features, you can check here.

THINGS TO NOTE!

• You don’t need to signup to use formspree, just add your action attribute and you’re good to go. You only signup if you want a Paid plan.

• Make sure your form has the method=”POST” attribute

• Formspree uses reCAPTCHA to identify spam submissions. After a user clicks our Thanos, they’ll have to do some CAPTCHA verification. Cool way of stopping spam submissions.

• After that, the form is sent to your designated email and the custom success page is displayed!

• Formspree does not read your form data, they have no access to it, they’re just a delivery service, you send your parcel sealed to them, they deliver to your customer, cool right? :)

• Formspree is free for 50 submissions per form per month ONLY! Need more, you can upgrade to the Paid plan.

• Formspree has both Free and Paid plans. Paid plans have several other features like admin dashboard, unlimited submissions, AJAX handling e.t.c Paid plans and their features can be found here

If you’re building a basic site, you shouldn’t worry about Paid plans, Paid plans are mostly needed by Enterprise applications and companies, the Free plan would cover all your needs. I use this for some client projects too :)

• Formspree premium users can submit forms via AJAX. Just set the Accept header to application/json. If you’re using jQuery this can be done like so:

    $.ajax({
        url: "https://formspree.io/FORM_ID",
        method: "POST",
        data: {message: "hello!"},
        dataType: "json"
    });

Well, this is for paid users :)

If you don’t use jQUERY like me and you’re tired of the lengthy AJAX default syntax, check out simpleAJAX library, a simple library I built for handling HTTP requests. Like so:

const http = new simpleAJAX;

const data = {
    "name": "Bolaji Ayodeji",
    "email": "hi@bolajiayodeji.com",
    "message": "hi"
};
http.post('https://formspree.io/FORM_ID', data,
(err, user) => {
    if(err) {
     console.log(err)
    } else {
     console.log(user);
   }
 });

A star would make me happy! :)

If you're into React, ZEIT has a comprehensive guide on using Formspree with Create React App, complete with deployment instructions. Highly recommended!

METHOD TWO

Netlify offers form handling for sites deployed on their platform.

FORM HANDLING WITH NETLIFY

• Create an account on Netlify and deploy your site there.

Please watch this 14min video by @JamesQuick below if you don’t know what Netlify is. Learn about all of the awesome features in Netlify like Continuous Deployment, Lambda Functions, Split Testing, Preview Branches, and more!

• Now that you have deployed your site, let’s create the form again

    <form action="/thanks.html" name="Bolaji's form" method="POST" data-netlify="true">
        <input type="text" name="name">
        <input type="email" name="email">
        <input type="text" name="phone">
        <input type="submit">
    </form>

Now let’s go over the new stuff I added above.

• Netlify is quite easier, you simply add the netlify attribute data-netlify="true"to the <form> tag, and you can start receiving submissions in your Netlify site admin panel.

• Here, the action attribute serves as your custom success page

That’s all, your form submissions goes straight to your Netlify admin panel

Settings > Build & deploy > Environment > Environment variables

(Watch the video above if you don’t understand what the panel means)

Things to note!

• Your site must be hosted on netlify to use this method

• You must add the netlify attribute for the form to work

• You can find all submissions to your Netlify forms in the Forms tab of your site dashboard. Settings > Forms

• Netlify has free and paid plans too

https://www.netlify.com/pricing

• Netlify has several built-in notification options for verified form submissions, including email and Slack notifications. (Only available in Paid plans). You can find them in Settings > Forms > Form notifications.

• Netlify also integrates with Zapier, so you can set up triggers that send your verified form submissions to any of the 500+ applications in their catalogue.

• All notification emails are sent from team@netlify.com, and any replies to a notification will go to that address. If you would like to respond to a form submitter, you will need to enter their address manually.

• Netlify Forms can receive files uploads via form submissions too :).

To do this, add an input with type="file" to any form. When a form is submitted, a link to each uploaded file will be included in the form submission details.

• Netlify is limited to 100 submissions per month and 10MB uploads per month for the FREE plan, If you want more, you’ll need to upgrade

form submissions in the admin panel

And that’s all!!

FINAL HTML FORM CODE

<!--formspree.html-->

<form action="https://formspree.io/you@email.com" method="POST">
   <input type="hidden" name="_subject" value="Bolaji's Form">                 
   <input type="hidden" name="_next" value="/thanks.html" >
   <div class="form-group">
      <label>Name:</label>
      <input type="text" class="form-control" id="name" placeholder="Name">
      <div class="invalid-feedback">
         Name must be between 2 and 20 characters
      </div>
   </div>
   <div class="form-group">
      <label>Email:</label>
      <input type="text" class="form-control" id="email" placeholder="Email address">
      <div class="invalid-feedback">
         Enter a valid email address
      </div>
   </div>
   <div class="form-group">
      <label>Telephone:</label>
      <input type="text" class="form-control" id="phone" placeholder="Phone number">
      <div class="invalid-feedback">
         Enter a valid number
      </div>
   </div>
   <input type="submit" value="Send" class="btn btn-info btn-block">
</form>

<!--netlify.html-->

<form action="/thanks.html" name="Bolaji's form" method="POST" data-netlify="true">
   <div class="form-group">
      <label>Name:</label>
      <input type="text" class="form-control" id="name" placeholder="Name">
      <div class="invalid-feedback">
         Name must be between 2 and 20 characters
      </div>
   </div>
   <div class="form-group">
      <label>Email:</label>
      <input type="text" class="form-control" id="email" placeholder="Email address">
      <div class="invalid-feedback">
         Enter a valid email address
      </div>
   </div>
   <div class="form-group">
      <label>Telephone:</label>
      <input type="text" class="form-control" id="phone" placeholder="Phone number">
      <div class="invalid-feedback">
         Enter a valid number
      </div>
   </div>
   <input type="submit" value="Send" class="btn btn-info btn-block">
</form>

CONCLUSION

One thing to note about formspree is that the free version leaves your email address exposed to scrapers and bots so you might want to set up a temporary disposable email address while you use it. If you want to hide your email address by default, you’ll need to upgrade your plan.

Do you want extra practice? Watch this tutorial video below by Brad Traversy and learn how to add a contact or any type of form to your website by using the Netlify form feature including file uploads and spam filtering. [Full guide + practical code]

Useful Links

• netlify.com/docs/form-handling

• forestry.io/blog/5-ways-to-handle-forms-on-..

• gridsome.org/docs/guide-forms

• zeit.co/guides/deploying-react-forms-using-..

• zeit.co/guides/deploying-statickit-with-zei..

Thanks for reading!

JAMstack is a modern web development architecture. It is not a programming language or any form of tool. It is more of a web development practice aimed towards enforcing better performance, higher security, lower cost of scaling, and better developer experience.

In this article, I’ll introduce you to what JAMstack means, why you should care, best practices, and how to get started. ?

Introduction

According to the official JAMstack documentation,

JAMstack is a Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

When we talk about “The Stack,” we no longer talk about operating systems, specific web servers, backend programming languages, or databases.

The JAMstack is not about specific technologies. It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

JAMstack is a major trend in web development coined by Mathias Biilman, the CEO and co-founder of Netlify.

Okay, chill! What is JAMstack?

You might have come across specific terms like MEAN stack and MERN stack. These are just terms used to classify or group some certain technologies with the aim of achieving a particular goal.

JAMstack here stands for

JavaScript

API

Markup

Stacks generally are just a combination of several technologies used to create a web or mobile application. So JAMstack is the combination of JavaScript, APIs and Markup. Pretty interesting right?

JAMstack projects don’t rely on server-side code — they can be distributed instead of relying on a server. Served directly from a CDN, JAMstack apps unlock speed, performance and better the user experience.

Useful Terms

I’ll be using these terms in this article frequently and I thought you should know their meanings (if you don’t already):

• API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other.

• CDN (content delivery network) is a system of distributed servers (network) that deliver pages and other Web content to a user, based on the geographic locations of the user, the origin of the webpage and the content delivery server.

• A Server is a computer designed to process requests and deliver data to another computer over the internet or a local network.

• A Database is a collection of information that is organized so that it can be easily accessed, managed, and updated

Why JAMstack?

Traditional websites or CMS sites (e.g WordPress, Drupal, etc.) rely heavily on servers, plugins and databases. But the JAMstack can load some JavaScript that receives data from an API, serving files from a CDN and markup generated using a static site generator during deploy time.

Sounds cool right?!

JAMstack is fast

When it comes to minimizing the time of load, nothing beats pre-built files served over a CDN. JAMstack sites are super fast because the HTML is already generated during deploy time and just served via CDN without any interference or backend delays.

JAMstack is highly secured

Everything works via an API and hence there are no database or security breaches. With server-side processes abstracted into micro service APIs, surface areas for attacks are reduced and so your site becomes highly secured.

JAMstack is cheaper and easier to scale

JAMstack sites only contain just a few files with minimal sizes that can be served anywhere. Scaling is a matter of serving those files somewhere else or via CDNs.

JAMstack Best Practices

• Use CDN to distribute your files rather than servers

• Installing and contributing to your project should be easy and less complex. Use tools like npm and Git to ensure standard and faster setup.

• Use build tools and make your project compatible for all browsers (e.g Babel, Browserify, Webpack, etc.)

• Ensure your project is up to web standards and highly accessible

• Ensure your build process is automated to reduce stress.

• Make your deployment process automatic, you can use platforms like Netlify to do this

How do I Get Started?

You can use some already built technologies to build JAMstack applications in a few minutes. Here are a few:

• Gatsby: Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps

• NuxtJS: NuxtJS is the Vue.js Framework for Universal applications, static generated applications, single page applications, progressive web apps and desktop apps

• Hugo: Hugo is the world’s fastest framework for building websites. It is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again.

• Netlify CMS: Netlify CMS is an open source content management for your Git workflow which can be used with any static site generator for a faster and more flexible web project

• Contentful: Contentful is a smarter and seamless content management system which provides editors and developers with a unified content thereby enhancing collaboration and ensuring digital products ship to the market faster.

• Svelte: Svelte is a radical new approach to building user interfaces. Whereas traditional frameworks like React and Vue do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app.

and many more. . .

Useful Resources

• JAMstack WTF

• How to Build a JAMstack Website

• What is JAMstack and why you should try it

• A JAMstack-ready CMS

• JAMstack for Clients: On Benefits & Static Site CMS

• Go static: 5 reasons to try JAMstack on your next project

• Static Websites + JAMstack = ❤

Find more resources here

Conclusion

JAMstack was invented as a way to put a nomenclature to the new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

JAMstack is not about specific technologies, it is a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

Join the JAMstack community to learn more and get more updates.

PS: This article was first published on my blog here