As many developers owning a personal website, I'm more willing to work on the website itsfel than on its content... 😅So when elm-pages V2 was released, this was the perfect justification to start over and rebuild everything from scratch!
Of course, this wasn't the only reason, leading to the perfect opportunity to talk about Jamstack!
First version
The first version of this website was built with elm-pages, a really cool tool created by Dillon Kearns to generate static websites. A static website contrasts with traditional websites because there is no generation of HTML, CSS or JS files at request time, all files are static and ready to be served.
With a static website generator, you can do the heavy work once at build time and then serve the page to many people in a fast and efficient way. In fact, this looks a lot like Single-Page Application, but there is a big difference: after the build, most of the data is already present in static website files. in a SPA, you would load those files and then load the data using HTTP requests to an API for example.
This brings many advantages: pages load incredibly fast, you can combine your website with whatever backend or content repository you want, your website is SEO-friendly and hosting infrastructure is simpler and cheaper as you only need a CDN. Conceptually, there also is a big shift: as most of your requests happen at build time, there can't be any failure at request time because your backend or data source is not available. You can write HTTP requests that won't fail, because if they do fail, it will be at build time and won't affect the live version of your website!
In the first version of this website the datasource was pretty simple: I was using markdown files for my articles, with metadata at the beginning of the file:
---
"type": "blog",
"author": "Author name",
"title": "Title of the article",
"description": "Description of the article",
"image": "Cover image, stored inside the GitHub repository",
"published": "2020-06-17",
---
Content of the article *using* __markdown__Writing a new article meant creating a new file with a somewhat limited user experience inside my IDE, even if I find markdown pleasant to write. The cumbersome part was that I needed to add any image inside the repository too and optimize them manually. So here comes version 2.
New version
Elm-pages V2 made far more easy to use GraphQL APIs as a datasource. That's why I've chosen to use a headless CMS I was using at work: DatoCMS. Their interface is really nice and I can use the media manager to import images, with a smart CDN optimizing them automatically. (Disclaimer: it's not affiliate marketing, I really like their product, but there are many other headless CMS that are really nice like Strapi).
A headless CMS is like a traditional CMS that don't handle the website appearance: it only deals with data and make it accessible through APIs (often GraphQL APIs as it's very flexible for the requester). Free from the complexity of displaying the data, headless CMS can really focus on having a great editor interface. In fact, this looks a lot like the separation of concerns in the Elm architecture where the update focuses on data and the view focuses on the appearance.
By combining a headless CMS with a static website generator, I've come across the Jamstack territory:
Jstands for JavaScript (well, in my case Elm, buts it's compiled in JavaScript after the build! 😄) In the JavaScript world, you can use generators like Gatsby, Hugo, ...Astands for API. Here, it's a GraphQL API from a headless CMS, but it can come from anywhere: a backend in PHP, Java, a public API, markdown files, etc.Mstands for Markup, meaning pre-rendered markup.
As I've said in the first part, there are a lot of advantages of using a Jamstack approach rather than a traditional server-generated website or a SPA.
First, your website has great performances because serving static files is easy with a CDN and can be scaled with almost no cost. Which leads us to the second point: the hosting is cheap, beause you don't need a dynamic server running to generate your pages. Third, jamstack is SEO-friendly, as your content is static and requestable by crawlers. If your datasource is down, your website is still available as it's already been built. Finally, you don't need to publicly expose your API to the users so it's a bit more secure.
Are there any drawbacks to this approach? If you data is often changing, it's quite expensive to rebuild the pages at each change. But nothing prevents you from doing some work at request time like in a traditional Single Page Application: you can request data that barely change at build time, then do an API call at request time.
For my website, I've bet on jamstack and I'm not regretting it! Having improved a lot my writer experience, let's now hope that I'll focus more on the articles and not on a future V3! 😄