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.
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.
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:
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.
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:
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.
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.
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.
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.
There are several reasons to go with this approach.
I’m excited about these changes, and what it means for my agency and my clients.
18th July 2020