JAMStack

Examples of non-JAMStack sites and their disadvantages.

Sites using a backend written in C#, Node, Ruby, Python, or other server-side languages. These tend to be older systems that predate the rise of single page applications. These systems retrieve data from somewhere and render it as HTML and javascript that is then sent down to the client. These systems can often be hard to extend, due to the large amount of custom code and its “quirks”. They are also vulnerable to issues with load and security issues related to retrieving data from the backend.

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.

Custom sites using a backend language to bundle javascript for isomorphic rendering on the client. A more recent trend has been to do minimal rendering on the server and rely on the client for this. Typical single page applications rely on this approach. While this reduces the load on the server, it can mean that the site is sluggish on client machines, especially if those machines are slow themselves. You still have to pre-render server-side if you want your content available to search engines, as google and the like still don’t do a great job reading content in single page apps.

The three parts to of the JAMstack

• Javascript

  Any dynamic parts of the front end are handled using javascript. This can be anything from vanilla javascript to larger frameworks. Because much of the content is pre-rendered, the amount of javascript actually required is often substantially less that you’d expect.

• APIs

  Operations that need to exist on the server for reasons such as security, are delegated to backend APIs. These APIs are accessed over HTTPS using javascript. You can build your own or use third party services built by specialists in a particular problem. For instance, you might a third party payment provider (like Stripe), a third party authentication provider (like Auth0) and ecommerce cart management using something like SnipCart. For a good example of this approach, check out Rob Conery’s course on Pluralsight on Serverless web applications.

• Markup

  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.

Build tools

JAMstack tooling handles a lot of the work of building a website out of a collection of loose files. This can include packaging files into compressed formats, rendering HTML, minifying and bundling javascript and CSS, and even image resizing and optimization. These tasks happen transparently on a server as a result of a trigger of some kind. Triggers can be anything from a commit to a certain branch, a regularly scheduled task, or even a call to a webhook.

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.

Images and other assets may be transformed during the build process, so there is less to do in the content development side of the system. For instance, you might transform images into various sizes so that they can display in different contexts. Similarly, you might compress and minify javascript and CSS files. This is also the step where you might render other views of your data, such as search indexes, RSS feeds, and tag and category pages.

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.

You’ll generally be accessing third party APIs using javascript and https. The cost of supporting HTTPS has gone down considerably since tools such as Let’s Encrypt. Additionally, if you aren’t doing anything security-critial on your own site, the APIs you use will be responsible for maintaining their own security infrastructure. This is far better than dealing with things like PCI compliance.

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.

Hosting static sites is far cheaper and requires less maintenance. Because the sites are just Javascript, CSS and HTML with a few other file types, hosting is often dirt-cheap or free. It also makes it really easy to switch webhosts. Most of the time, you simply deploy to a different location.

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.