Since first hearing about Netlify and the associated JAMstack, I was intrigued — it appeared to be a great choice for sites serving mainly static content so it could really save time and money for simple shop-front websites.
To see what Netlify could do, I decided to have a go at using it to update the Kingston Labs website. The website had previously been implemented in a Django stack using AWS (Amazon Web Services). This article looks at architecting a new setup with Netlify instead of Django.
What is JAMstack?
Before starting, it would be useful to know a bit more about Netlify and its so called "JAMstack". JAMstack stands for 'JavaScript', 'APIs' and 'Markup' — it's not a great acronym given that all those things are used in virtually every web stack, but it does serve to emphasise the stronger focus on those elements.
For me, the most important thing to know about the JAMstack is that pages are generated at build time rather than at run time — this provides a huge benefit in that pages can be served statically over a CDN, meaning that they are both extremely fast and highly reliable (no need to worry about pesky server errors!). Of course caching layers can significantly help dynamic frameworks like Django, but that requires additional setup time and has more potential for errors.
As you might expect, there is a significant drawback to only serving static content pages — sometimes you really need things to be dynamic. For example, on an e-commerce site you probably want to show what is in the customer's basket, or on a blog site you may wish to provide a search page. This is where the 'A' part of the JAMstack acronym comes in: 'APIs'. These may operate in a number of ways — through a JavaScript request to an external API; using Web APIs (particularly the Storage API); or using serverless functions.
Choosing a Framework
The existing stack was a simple Django site built on AWS. This originally required an EC2 instance with an S3 storage bucket for static and media assets with a Postgres database. We had already altered our architecture to use Django's serverless app, Zappa with an SQLite database instead of Postgres, keeping costs low with very little required in the way of maintenance.
Reading the Netlify docs, it was apparent that there was a big choice of site-generators, from vanilla implementations to more complete frameworks.
It would actually be possible to use a Django management command to build static pages and then serve those with Netlify. In fact, there are actually a few Python site-generators designed specifically for the job such as Pelican or Hyde.
Rather than choosing the Python route, I decided it would be best to take a look at the most popular generators currently available:
- Gatsby: an open source framework built on React and GraphQL
- Hugo: a framework built with Go
- Middleman: a framework built on Ruby
- NextJS: another React framework, with a focus on server-side rendering but also including static exporting
- Nuxt: the VueJS equivalent to NextJS
- Jekyll: a simple framework built in Ruby, designed for use with GitHub Pages
One of the great features with these are the templates which allow you to quickly push to your git repository and deploy a starter project at the click of a button. I found this particularly useful in making a judgement on each framework since it allows you to test out different set ups really quickly.
Initially I experimented with a vanilla WebPack implementation that just put together a number of pages along with some JavaScript and CSS. This went well, but I soon discovered that adopting a more complete framework would speed up the process for building out more complex features such as a CMS.
I tried out the Netlify CMS starters for both Gatsby and Hugo and discovered that both of these offer very similar functionality. Hugo seems like it could be a really good option, but since I have a lot more experience with React and GraphQL, I decided to go with Gatsby in this case.
Gatsby
I've always tried to avoid Single Page Apps since they usually depend so heavily on JavaScript — I believe it is important that a website can fall back to display the core content in case the JavaScript fails.
Gatsby's features really shine here since it works by 'rehydrating' the DOM. This means that if the JavaScript fails, the content of each page is still served (although without all the fancy JS flourishes). This is great for accessibility, potentially benefits SEO and reduces dependency on client-side technology.
The GraphQL engine also provides some interesting features, allowing functions to be performed on data before rendering, for example the Remark Transformer plugin allows markdown files to be converted into HTML.
Implementation
In our next article, we will be looking at how each feature of the website was implemented using Netlify and Gatsby as well as some of the challenges involved.
If you have any questions or would like to tell us about your experiences with Netlify, add a comment below.