Going all-in with JAMStack

I’ve been building websites under the Kelly Creative Tech brand since 2008. For most of that time, I used one version or another of a custom Content Management System (CMS) that my brother Issac and I built. Building our own CMS was an exciting challenge, and in many ways was the catalyst for both of our careers.

The internet changes quickly though, and there are some exciting new technologies that have caused us to reconsider how we build and deliver marketing websites going forward.

What is the JAMStack?

JAMStack is a new way of thinking about the role of computational work for websites. “JAM” is an acronym for “Javascript, APIs, and Markup”, and “Stack” is a traditional way of describing all of the technologies that go into hosting a website.

What is a website though, really?

Every URL on the web points to an HTML file, which the user’s browser downloads and renders as a web page. Without any CMS, it’s possible to write an HTML file by hand, store it on a hard drive (whether on the internet or on a thumb drive), and open it with a browser.

Why do we need a CMS then?

A CMS allows a person to edit a website without knowing how to write HTML. Until very recently, all CMS systems (including ours) shared a similar model:

• Content is saved in a database on the server.
• Templates are where the design lives. HTML, CSS, and JS files live in a static folder on the server.
• The admin interface allows authors to log in and make changes. This can appear like anything from an excel spreadsheet, to a form, to an editable copy of the website, but they all do the same thing: save content to database fields.

In this traditional setup, when every public user visits a URL, the CMS builds something that didn’t exist before: It combines the content from the database with the template to build the page. (Caching can be involved, but just let me keep this simple.)

In this system, there is one server that does all of this work, and it’s largely focused on rendering the page at the time the user requests it.

How is the JAMStack different?

The JAMStack model decentralizes all of this work. It relies on several specialized services, and allows the web developer to choose exactly the right tools for the job. Further, the computational work – the actual compilation of the HTML file – only happens when the content is changed in the CMS, rather than on every page request. This allows the entire website to be hosted on a server with no backend programming allowed. There are several benefits to this method:

• This saves computational power (because the computational pieces do not have to be 'always on', to build the HTML page on demand for each user, each time it is requested). That's good for the environment, sure, but it also means that the website is crazy fast. That's good for your users (because who likes to wait?) and for your search engine ranking (because Google rewards websites that care about performance.)
• It increases security (because in the most popular CMS systems, the database is typically the most vulnerable piece. We've removed the database, so to the public, there's nothing to hack into.)
• It improves durability of the public site (because if anything becomes corrupt or out-of-date with the CMS software, the public-facing site is completely unaffected while the problem is resolved.)
  

There are many ways to build a JAMStack website, but for the scope of this article, I’ll focus on the approach that I most often use, based on Gitlab CI, the Eleventy Static Site Generator, and Netlify-CMS.

Eleventy Static Site Generator (SSG)

A “Static Site” is a website that does not interact with a database. If you write an HTML file and upload it to a server, you have a static web page. A Static Site Generator is an application that compiles templates together with a folder full of text files to compile a completed static site. Eleventy is one of many static site generators on the market, but its versatility and ease-of-use make it a clear favorite for me.

It’s possible to stop there.

As a site editor, it’s possible to install Eleventy on your local machine and configure additional tools to deploy the completed site to the hosting account. (As I’m building sites, that’s what I do.) For most clients though, that’s a lot to ask.

That takes us to the next piece.

Gitlab CI

In order to run Eleventy (which builds the site), it has to be installed somewhere. When it is installed on the developer’s local computer, it can be set to run the whole process every time a file is changed. For example, if the developer makes a change to the ‘about’ page or the “contact.html” template, Eleventy is watching. “Something has changed! Build the whole site again.” For most sites, that process only takes a few seconds.

As I said previously, it’s a lot to ask to have a client install command-line tools on their computer just to make updates to their site. This is where Gitlab comes in. Gitlab offers “Continuous Integration” tools that allow a developer to install a set of code that is installed and run as it is needed.

In this case, the developer hosts the code for the site on Gitlab, including some instructions for Gitlab’s serverside processing services. The developer writes a few lines of code that say “If a file is changed, install Eleventy and run it, then deploy a copy of the site to the hosting account.” This process usually takes a couple of minutes.

So now, rather than have a client install Eleventy on their computer, I can give them access to a Gitlab account. With a little instruction, they can edit plain text files, and on Save, Gitlab CI will fire up Eleventy and deploy a fresh copy of the site.

Again, it’s possible to stop there.

Most people can edit a plain text file, so this would work fine if a client isn’t expected to do much more than change a contact name or phone number occasionally. Anything beyond that, and the developer will likely be fielding support requests to add photos, fix a blog post, etc.

With a little extra effort, it’s possible to provide an editing experience that feels like a traditional CMS.

Netlify-CMS

With the site deployed using Eleventy and Gitlab CI, it’s possible to include a few configuration files to install Netlify-CMS. This system interfaces directly with Gitlab in a user-friendly way. With a Gitlab account, clients can log in to /admin on their own domain and make changes, very similar to how they would with any other CMS. The difference here is that it’s still not saving content to a database. Instead, when the user hits ‘publish’ in Netlify-CMS, the changes are made to the text files on their Gitlab account, which Gitlab then sees, and begins the process of deploying a new copy of the website to the hosting account.

If you’re interested in seeing a quick demo of the Netlify-CMS interface, here’s a brief video.

This all seems complicated. Why?

There are several reasons to go with this approach.

1. Security. If there is no database, chances of being hacked go down. The only point-of-entry to editing your website would be the user’s Gitlab account, which allows for two-factor auth, and e-mail alerts on every change, should the user decide to set that up.
2. Flexibility. These systems are fairly inexpensive, and easy to switch out. If for some reason you need to switch to Github instead of Gitlab, or change hosting providers, the code can still be run the same way, and the site can be hosted anywhere that allows integration with CI deployment tools. My clients are now hosted on Gitlab Pages, Github Pages, or Amazon S3, and the transition between them is fairly seamless.
3. Techical debt. Every software project comes with some amount of technical debt, or the amount of work it takes to maintain security updates, bugfixes, etc. Having more companies and more software packages involved may seem like there are more moving parts, but the reality is that if we’re unhappy with any one piece of the system, it’s much easier to switch that piece out without starting the project over. It means that projects can be more “evergreen”, allowing for incremental changes over a longer span of time.

I’m excited about these changes, and what it means for my agency and my clients.

18th July 2020