So a while ago, i started thinking i should blog about code again. My old blog has perished quite some time ago after i neglected my duties as a dev to share my experiences in the android development world. The old blog was made with Wordpress with a similar theme to what i have now (thanks hyde-hyde). I have been using Wordpress for ages it seems, in-fact - it was at some point in my life, a way of making a living.
A friend on #android-dev over at FreeNode (IRC for those who dont know) suggested i should try a different stack rather than the familiar lamp/lemp stacks that i have previously used to build my sites and blogs. JAMStack he said, which i have never heard before. Soon after, another friend jumped in and mentioned Hugo, another thing i have not heard before.
For the lazy: jump to resources
So what are JAMStack and Hugo? Lets start with JAMStack:
“Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.” JAMStack official
That sounds fantastic, but what exactly sounds so fantastic? For Example, lets review the LAMP stack which we use for say, a wordpress blog. LAMP which stands for:
- Linux
- Apache
- MySql
- PHP/Perl/Python
Now, most users who blog on wordpress never have to worry about this LAMP stack. in fact, i am sure most of them never heard about all of this before. but we still need all of it to run a simple wordpress blog. On the back of a simple wordpress blog, theres a lot of magic that needs love, with each part of the LAMP, let alone wordpress itself, can be targeted by evil doers and bored kids. Now, most people need not worry about it. Their host does that for them, keeping the OS updated, the webserver, the PHP and all the plugins, the DB. But when push to comes to shove, and your blog loads as if its a page on a BBS in 1993, you start adding caching plugins, some which are very complicated to get right. And even then, a lot needs to be reconfigured to get a fast and smooth experience, and sometimes that’s not even gonna cut.
And JAMStack?
JAMStack stands for JavaScript, API and Markup + stack. What does that mean? Simply put as the official docs state: YOU DO NOT DEPEND ON A WEB SERVER. What do we depend on? Not much really: a static page which can (but might not) make api calls via JS in the users browsers if and when needed. Basically, we do not need anything other than a webpage and a CDN to host it, git and a remote git repository host. If all we are doing is showing the same data over and over, we can let our CDN provider handle all of that for us - and we, as site owners/devs, just need to push to that CDN the most updated content we have.
Enter Static Page Generators.
There are a lot of them out there. There’s Next.JS, Gatsby, Jekyll, Hugo and others. While i wont dwell into the differences between them, they all share one common thing: they generate static pages when there’s actually a change to the site.
So why Hugo? Well lately i have been picking up on GO, and Hugo is written in GO, so i thought to myself: surely that will come useful some time. Also, Hugo has fantastic documentation, something a lot of providers miss. And lastly, my friend from IRC recommended, i dived right in, and now im in it. #noragrets.
While the Hugo quickstart manual is fantastic, here are the key steps to get an up and running, at least locally, a site:
- installing Hugo
- creating a new site
- git init
- add a theme as a submodule
- git commit
- add content
- git commit
- deploy on a local hugo server
And there we have it. The site is running, themed, and now we want to publish it out, so the world can see and share its glory.
Enter Netlify
The last part of our holy trio is Netlify. What netlify provides to JAMStacks is a CDN and a CI Solution (check out their free plan for limitations), one that requires almost zero effort from the dev itself. All one must do, is to connect and authorize his/her github/bitbucket/gitlab site repository with Netlify, and that’s about it. Now every push we’ll make to our OBSERVED branch, will trigger an automated build of the site and deployment to Netlify’s CDN. Lets examine the process:
- git init on our local site main folder.
- push to github/bitbucket/gitlab
- authorize Netlify on the relevant repository
- do some changes locally
- commit && push to remote
- automatic deployment by Netlify
To Conclude it all.
By using JAMStack we cut back on a lot of technologies we need to control to get our site up and running, while secured. By connecting ourself to a service like Netlify, we avoid having to deal with the caching of the site for faster delivery. It’s a cdn, its fast. By using Hugo we get a static site generator which is properly maintained and well documented. We have no server, at least not one which we control, we have CI out-of-the-box, and our pages are cached on a CDN. I call that - a win.
Resources
Fantastic Tutorial by Travis Media:
Great Talk by Phil Hawksworth:
Issues && Problems
Editing a theme seems like a giant PITA. Since we add themes by telling git to add a submodule (and refrencing it in .gitmodules), and any changes we do to those theme files we can not actually push upword (we just wanted to edit the theme to our liking, no PR), a workaround i have found online directs that we first fork the theme to our remote git repository, make changes to the theme, push it to our fork, delete the local theme folder, re-fetch the fork theme that we have done the editing. This is not clean, and not very user friendly to work with.
Another solution states we can actually include different files which will act as overrides to any theme template or static files, by putting them in our working directory. more info can be found here.