I’ve made the switch! The Full Stack is no longer powered by WordPress Let’s talk about the nitty-gritty details.
As you probably know, WordPress is the de facto blogging platform that runs websites. In-fact, each time you visit a website there’s a 25% chance it’s powered by WordPress.
WordPress is 25% of the entire internet, let that sink in for a moment.
So when it came to create “The Full Stack” choosing WordPress seemed like the obvious choice. I wanted to focus on writing and thought WordPress would be the best way to get up and running quickly.
But the more I wrote, the more I started feeling like an imposter. Here I am talking about all of this JavaScript awesomeness on a website running on PHP.
That had to change. And it did.
Not Invented Here Syndrome
The first question I asked myself was whether I should roll my own blog or use existing JavaScript blog/CMS framework. Here is a taste of some of the great options out there:
I’d be lying if I said none of these filled my specific needs. In-fact, every one of them filled my very non-specific need of “I need a decent blog that runs on JavaScript.”
But I decided to roll my own my blog. I figured it would make a good side project opportunity.
I was also curious to see how much work it would take to replicate my WordPress blog’s core features. I’m ignoring the entire WordPress “Admin Panel.” Since I only have one user, which is me, I realized my entire user base doesn’t need an extravagant admin panel. A git repo with markdown files is all I need.
The New Full Stack
To make my transition from WordPress a worthwhile undertaking I decided to set to myself several hard requirements I didn’t want to deviate from:
- Performance - With varnish and several caching plugins I’ve managed to pull off “not horrible” performance in WordPress. For the new blog, I’ve set the bar at 90+ Page Speed Insights score.
- HTTPS - I’ve had several issues with plugins and configurations when trying to move the old WP site to https. The new site had to be https only.
- SEO - The new blog had to be as SEO friendly as my old site. This includes Schema.org properties, SEO related headers and so on.
- Style - Had to look as similar as possible to the old WP blog template. I didn’t want to change the styling or structure of the site along with everything else.
- Markdown - Posts will be written in markdown and converted to HTML automagically.
- Universal React - UI components should be React based. First-page load should be prerendered. Following page navigation should be SPA style.
- URL paths - Posts and pages will retain the same URL paths they previously had. Site
- Sitemap, RSS and Special Features - Should support blog features that allow easy consumption for RSS readers and crawlers.
It’s been a fun project to work on. Pulling together many different npm modules to create a functioning blog was both challenging and satisfying. To my delight there were mature libraries for everything I needed. Here are the most notable ones:
- Next.JS - Universal React + Routing + a bunch of other useful stuff. For any universal app that has a concept of “pages,” Next.JS is worth a look.
- React Semantic UI - Definitely an overkill for this blog. I use a handful of components like the nav menu and share buttons. But I can’t live without Semantic UI, so it’s here.
- Markdown-It - Turns markdown to HTML. There are about 5 different popular markdown engines to choose from in the node ecosystem. Markdown-it isn’t the most popular but it has the best plugin support.
- Highlight.JS - Code highlighting. Built-in support by markdown-it.
- Node-RSS and Sitemap.JS - Both packages perform their namesake quite well.
- Fuse.JS - Fuzzy search functionality. I tried Algolia at first but there was really no need.
- Nprogress - Great progress bar for single page apps. Plays well with Next.JS.
- Mailgun-JS - A Node.JS Mailgun client. Mailgun sends me an email every time someone submits a “Contact Us” form.
Hosting, Deployment and Monitoring
This website is hosted on the Hobby tier of Heroku. For 7$ a month it’s a pretty good deal. I’m running in cluster mode with 3 Node.JS workers. This keeps me below the 512 RAM quota and should handle traffic spikes decently enough on this scale.
The real test will begin as soon as I publish the post you’re now reading. I’m curious to see how well I’ll fare with the spike in traffic.
CloudFlare is used to handle traffic and do a bunch of cool stuff like forcing https and caching. CloudFront is used as a CDN for static assets. NewRelic and StatusCake are used for monitoring.
I’m using a GitHub private repo to host the code. Publishing a new version or an article only requires a push to master as Heroku has built-in GitHub support.
Overall the entire operation cost is about 10$ monthly.
Editorial Changes
My first post here was on December of 2015. A lot has changed for me since then. I’ve switched jobs, moved apartments, became single, got promoted and a bunch of other important stuff.
But what hasn’t changed is my firm belief that “All else being more or less equal, Full Stack JS is the way to go.” I hope to be writing much more frequently now that The Full Stack V2 is out.
I would also like to start sharing some posts here that aren’t JavaScript specific. But related to programming and development cycles in general. Perhaps some writing on startups, technical team management and self-management as well.
I hope you’ll join me as I share new tidbits and insights about the ever evolving world of Full Stack JavaScript, startups and software development.