Instead of either of these approaches, the JAMstack approach is designed around static files that typically expose all the content available in the site and can be deployed to a content delivery network (CDN). The idea is to only use APIs and the like when they are truly required, rather that when they are just a little easier. Basically, this approach seeks to front-load the work of rendering pages so that the hosting server and user machine are required to do very little to display the content.
The JAMstack is a response to some of the problems caused by traditional approaches to the development of content-heavy websites. It makes it easier to scale sites, reduces the attack surface of content sites, and can often be substantially cheaper to host.
Examples of non-JAMStack sites and their disadvantages.
Web-based content management systems like WordPress, Joomla, Drupal, Dotnetnuke. These are often pretty easy to get set up and have good communities around them. They also tend to require a backend database in order to function. Because they tend to load data from the database and render it as HTML that is sent to the client, they have significant vulnerability to web-based attacks and are fragile under load. Additionally, if you are doing anything that isn’t supported by the core of the system, you tend to need plugins to accomplish it. This can lead to an entirely different set of security concerns.
The three parts to of the JAMstack
In JAMstack, templated markup is built at deploy time. This means that your markup can come from most any datasource, including datasources that you don’t want to expose to the open web. The rendered html can be optimized for different devices and use cases as well. For instance, you can render both as HTML and as JSON, for different consumers. Many of these generators use Markdown to make editing simple, but that is not required.
How JAMstack sites are developed.
Typically, you develop locally, using your own machine (rather than connecting to a server) until you are happy with the content and layout. This makes JAMstack sites very easy to work on when you are on a spotty or non-existent internet connection, provided that your data sources are available. This also means that you can use general purpose development tools for much of the work. This also makes distributed workflows easier using tools like git.
Next, you commit your content to source control, which triggers an automated build. Github and many other source control systems can be set up to make a call to a webhook when something is committed to a particular branch in the system. Automated builds can also be done in a scheduled fashion, so you could do things like redeploying the site early in the morning every day, or even checking hourly for changes. The source control systems also allow your to branch and merge, so this allows your workflow to include code and UI changes on one branch, while simply content on another.
The automated build will run the rendering process and deploy your code to production. Unattended and automated deployment means that your live site can quickly be updated after a push, without your intervention. This also means that if the production site is compromised in some way and the backend source control is not, that you can quickly redeploy to correct the problem.
The automated deployment will also take care of things like cache invalidation, and make sure that the site is atomically updated. Since larger sites tend to have a lot of files, there exists the possibility that someone will visit your site in the middle of a deployment. Many of the tools built around JAMstack also allow for atomic updates, which keeps this from happening. Either the old version of the site is available, or the new version is available, not a hybrid of the two. Similarly, since you may be deploying to a content delivery network, you need to make sure that users don’t have an old copy of the code. Many of the tools used in JAMstack can automatically invalidate cache.
Once the relevant files are created locally, the build server will then copy these files to a staging location on the remote server. While you certainly can directly directly copy to a production location, this means that your site will be in an inconsistent state for the duration of the deployment, and could easily be broken during a failed deploy. Instead, common practice is to first deploy to another location on the same server, and the copy over to the new location from there. This drastically limits the amount of time that the site is in an inconsistent state.
If files are being deployed to a content delivery network, the build script should do so. Content delivery networks can take care of making sure that the required files are deployed close to the people who are accessing them. Under the hood, this means that many copies of the same files are distributed across the internet. The typical expectation with CDNs is that your files will eventually be updated, not immediately updated.
How content is built.
Most systems use markdown files on disk for most content. Markdown is trivially convertable to HTML and is built to be extremely easy to use, even for non-technical people. Such markdown files also tend to include a section at the beginning, called front matter, that specifies metadata about that particular piece of content. For a good markdown tutorial, check out Daring Fireball’s tutorial.
Content can also come out of another system. Headless CMS systems are good for this. They allow content creators to write content that is then exposed through an API. You can also use wordpress as your editor on an internal site and then expose your content through GraphQL and other API types. The point of this is that the content is retrieved at build time, rather than at run time.
Some commonly used JAMstack tools. Just some of the common ones.
Jekyll: the granddaddy of them all.
Hexo: A favorite of this podcast. We use it for Developer Launchpad.
Gatsby: A rising star that is built around react and GraphQL.
Hugo: Built around Go.
Next.js: framework for statically exported React apps.
Gitbook: doesn’t build websites at all. Builds books instead, using the same principles.
Handling server-side stuff
If you are building a site, odds are good that you are going to need at least some server-side functionality. This might be for payments, for authentication, or for other security-sensitive parts of your site. While you can build these yourself, you can also use tools built by people who are specialists in that particular problem domain. If you use third party systems for common things, they also tend to have already built the required backends to support them, so you end up only working on things that distinguish your site from others.
The downsides of JAMstack
A few things are more difficult with JAMstack. If your site is membership-based, you probably don’t want your members-only assets to go through the pipeline that builds the rest of your site. This adds overhead. It takes a fair bit more effort to set up a JAMstack-based site than it does to set up a wordpress site. You will need familiarity with the toolchain you are using to build your site. You have a lot more flexibility with JAMstack than with other types of sites. This can make it more challenging to get a good solution out the door quickly.
You may also have some difficulty with integrations. It’s common for third-party services to offer prebuilt components to integrate with their systems. It’s not common for them to do the same for static site builders. This means dealing with other people’s APIs and potentially having to quickly update in response to changes.
What JAMstack can do for you.
It can save you a lot of security pain. Big content management systems are subject to constant attack. WordPress is particularly bad for this. When there is no backend, it greatly limits the available attack surface. You don’t to be as concerned that somebody will breach the system and start using your site to sell knockoff purses. Additionally, mitigating a hack is easier. You just redeploy.
The frustration that most developers feel around whiteboard interviews and what lead Will to write this book likely started back when he first got into software development. Then came up again when he was mentoring and training BJ as an apprentice, throwing erasers at his head. What ultimately got the ball rolling on this book was when a friend mentioned at a Developer Launchpad meeting how she hated that she couldn’t practice and study for whiteboard interviews easily. That lead to a conversation between Will and BJ about introducing the whiteboard problems to the Coding Jam sessions. Then Will went further and wrote a rather popular episode and started giving talks at local schools on surviving the whiteboard. Finding he had a larger audience than just the students he was reaching each semester he began the task of writing this book.
Tricks of the Trade
When something really good or really bad happens, put it aside for a bit before you react. You may not have all the information you need, and something else may happen in the interim. It’s a good way to stay level.