My first website
My first website I built using Django. I didn't know any javascript and I only knew a little HTML & CSS, but I was able to follow Corey Schafer's Django series on Youtube.
That site cost me $5/month on Linode. I think I used that set up for almost a year. One major problem I had was the 'post' editing with Django's backend. I understand there are ways to make the editing better, but the solutions weren't very obvious and I lacked the patience to dig into Django.
This website had a few pain points:
- manage a production server
- login to the server every time I need to pull changes
- deal with a bad bad content editing setup
I actually set up some kind of markdown to HTML converter that allowed me to write in markdown, which was a little band-aid on the issue.
After rolling with this set-up for almost a year (?) the first change I needed to make was the way I handled the content.
Content management systems
I first heard about headless content management systems on Software Engineering Radio Episode 388 and thought it might be the answer to my problems. After a quick Google dive, I landed on Sanity.io.
I like Sanity, but I would suggest a client use Contentful if they can afford it.
Sanity has an awesome starter plan.
As a side note, Sanity leaves the door wide open for customization. It doesn't come with as many editor features as you might expect, but a developer can get their hands into the studio and create some cool things.
I moved some content into Sanity, created a serverless function on Azure utilizing a Sanity package that converted block content into HTML, and fetched the HTML for the Django site. Unfortunately, that took too long to render (the function needed to 'warm up' and I didn't have enough traffic to keep it hot).
This was a step in the right direction but I still had deployment, development, functionality, and appearance issues. Summer 2019 I started learning Javascript.
My website round two
I rebuilt the site with Node.js and React.js. That fit well with Sanity and it fit with me. This still kept my monthly price at $5/month on Linode. However, along the way, I added two expenses that weren't directly for the site, but the site benefitted from the spending.
I had a slick way to add, query, and manipulate content with Sanity and their GROK query language.
With my new Linode server, at $5/month, I had a site that I liked more, looked better, and was comfortable building out. I was also able to edit my content easier, but I was still logging on to the production server, pulling changes, and running a build when code was changed.
What else was missing?
I had a React.js and Node.js site. I had a production server, with no continuous deployment (CD) set-up, so I was logging in and building the site when I had changes. Furthermore, I started to research issues that come up with React and search engine optimization. I had news problems to solve.
I spent almost a full day configuring a Jenkins server, and configuring the Linode server the website was on, so that I could have CD. I had planned to stick with this set up for a while and even created a Linode build script to help the process.
As for the SEO problems, I read about using server-side rendering, static site generators, etc. I liked my new React/Node site but I couldn't justify having a website with the chance of such poor SEO.
Despite the concern, I didn't learn about static site generators or server side rendering options. I found myself distracted by Netlify.
Netlify
I fell in love with Netlify. I moved three sites there almost immediately. I deployed my website to Netlify to test it out and had the same site—but now—I had this instant CD set up. That was cool. I immediately shut down my Jenkins server: indefinitely.
Moving my site to Netlify allowed me to;
- Stop paying for a production server
- Get immediate continuous deployment functionality
- Decrease my development and deployment time with functions and server set up
It was so clear to me that this was the direction my site needed to go in. I only had one or two API routes on the server that I used anyway, and Netlify has a simply process for developing and deploying lambda functions as part of the project. I switched three sites to Netlify in a frenxy and proceeded to 'chill out'. I felt remarkable about this progression.
I thought that I had discovered my new golden process. Little did I know I was missing one last piece of the puzzle. Within a week I found myself reading about Gatsby.js.
Gatsby.js
I heard whispers of Gatsby on Sanity's slack channel ("sanity-io-land"), but I can only take so many .js's in a month. I finally built up enough curiousity to check it out.
The GraphQL stuff was a little bit foreign, but I figured I would try it out on my blog site (that I had also switched to a Node.js/React.js site hosted on Linode). I ran the Google Chrome lighthouse audit, because I heard I could check performance with it, and was speechless. I sat there and my mouth literally dropped.
I can't remember the exact number, but my blog site's performance score—the one that was rendered with the Linode server—was somewhere between 20-40.
My new score was in the 90s. I ran it again while writing this and it's still at 94. I uncontrollably rebuilt three sites to use Gatsby.
I feel like a JAMstack groupie now. I'm not a bonified JAMstack expert, but wherever it goes I'm tempted to follow. I certainly haven't run an npx create-react-app in awhile.
I have a couple sites running on the Gatsby + Sanity + Netlify set-up and it's going to be difficult to change.
In closing
Consequently, I'm aware that this means I'm not able to run realtime data like I had done before with Socket.io, and if I was doing heavy work with a database I may need to go a different route.
All that being said, it's funny to reflect on my beginnings with Django and my gradual slide—and subsequent fall—into the current stack.
Thanks for reading about my tech journey over the last couple of month!
