Making a blog from scratch has been on my project to-do list for a while, but I wasn't sure how to get started. I thought the database and admin authentication would be the hard parts, but it turns out that I shot myself in the foot by choosing GatsbyJS as a frontend framework a few months ago. Some things I learned about while working on this blog:
- User authentication (using Auth0)
- Databases (MySQL)
- GraphQL
- Client-only routes
- Code syntax highlighters
- Why I'm never using GatsbyJS again
First, I set up a MySQL database to store the blog posts. I'd never used a database in a project before, so I wanted to understand how it would fit into the program flow before getting too far ahead of myself. At this point I wasn't sure what format the post content would be stored in, such as HTML, markdown, or plaintext. I wanted that choice to be driven by whatever UI text editor I decided to use on the frontend. It ended up being a string of HTML generated by a what-you-see-is-what-you-get editor. That's what I'm typing in right now!
This video series was helpful for getting up and running with MySQL and an Express/Node.js backend. I've used Express before, and connecting to my local database was easier than I thought. Pretty soon I was able to write some CRUD API endpoints with Express to fetch, create, delete, or like a post, and test them with Postman. For deployment, I hosted the backend and database on Heroku.
After setting up the backend, the next challenge was figuring out how to display a blog post as its own page on my website, with its own unique URL. At first, this seemed like it would be the easy part. I've used router components to programmatically create pages based on data, and that was my initial plan for this project. GatsbyJS, a React-based frontend framework that I've been using for my whole website, had other plans. This led to a few days of banging my head against a wall. Gatsby offers three ways to create routes/pages, and using a router component isn't one of them. It does include Reach Router behind the scenes, but it wouldn't let me set up my own router within one of my pages to handle blog page routes.
So, I tried to play along with Gatsby by using the createPage API. With this API, you can fetch data and have Gatsby generate pages from that data. This solution seemed to work, until I tried to deploy. Everything always seems fine and dandy until you try to deploy. My project couldn't pass the build process because I forgot that the project can't make API requests during build-time, because it's running on a server and not a browser. This means that it couldn't handle the request to fetch posts from my database, so it didn't have any data to generate pages for. I found a Gatsby-esque solution to this, and used GraphQL (made by Facebook!) to pull data from MySQL into Gatsby's data layer. This approach relied on a very specific, not very customizable plugin made by a Gatsby community member. Pulling data from MySQL to GraphQL solved my initial build errors, but introduced some deeper problems:
- A mysterious, non-deterministic timeout error that would cause the build process to fail during deployment to Netlify, but not on my local machine. The error said it exceeded a timeout of 30s, but it errored in under 1s?
- GraphQL only populates the data layer at build-time, not runtime. This means that any new posts I created wouldn't show up unless the server restarted. I don't have control over that on Netlify, so that was a big problem. If there's an option to refresh GraphQL with Gatsby, I couldn't find it
At this point I was pretty frustrated with all of these limitations and rigid plugins from Gatsby. I experimented with its File System Route API to create client-only routes as a last resort, but that also relied on GraphQL so it didn't solve the underlying issue. Although I have to admit, that API was pretty magical. Ultimately I decided to give up on Gatsby, and spent an hour trying to extricate my codebase from its clutches. After all of that, I was able to implement my original plan of using a router with no complications.
The last piece of the puzzle was setting up user authentication to make myself the only site admin. This would let me create and manage content, unlike the rest of you plebians. There's two layers of security here:
- There's a secret user login route on this website that isn't in the nav bar, but you could find it if you looked at the codebase
- Login with Auth0. This is the real no-shit security
Setting Auth0 up was pretty painless thanks to this guide. Once I'm logged in, I get access to some buttons that let me edit or delete posts, and I can create a new post through the admin panel. The image below is what I see when I go to the admin panel to create a new post.
Overall, I had a great time building this blog aside from wrangling with Gatsby. I'm not scared of using databases anymore, and I already have some ideas for how to use them in my other ongoing projects! I also spent way too long choosing a color scheme for the code syntax highlighter, because that's who I am as a person.
function test() {
return "look how cool this syntax highlighter is!"
}