Building a blog with NextJS and Prismic

I go through spurts of focusing on this blog. It’s something that I know I should do and enjoy when I get a chance to work on it, but it always seems to get neglected. One of the most significant issues that I usually run into is the constant reworking of the design and frameworks that I use to build it. My very first blog was created with Jekyll when I first began working in tech. I was learning Ruby, so it made sense to use Jekyll, and it was one of the more popular static site generators, maybe even a static site before static site generators were a thing. Since then, I’ve rebuilt it with many different technologies, some that made it to the web and others that never made it off my local machine. Gatsby, Hugo, and NextJS. But that’s just part of the issue. The next consideration is how to manage the content. Again there are many options here, and I have gone through a bunch as well, from markdown files stored in the repo to headless CMS options like Contentful and Prismic. These choices begin to drive different decisions that will need making, such as languages to use and frameworks to help make it a little quicker and easier. Then comes the question of the design. Yet another thing that I have gone back and forth with over the years. From a site that mainly was a clone of the Ghost Casper theme to where we are today. Finally, made all those decisions? How about how and where you plan to host it? Same issue here. There are many options out there, and I have gone through a few. From manually setting up Heroku to Vercel to Netlify. Decision fatigue at its finest. All these decisions will need to be made to get working and need to be made well to not continuously backtrack and spend time on the site development versus the site content. That is the essence of my blog dilemma today. I end up spending more time on the development of the blog vs. the content of the blog. The question is, how do you change that? This post is my attempt to walk through how I am deciding to figure that out. So let’s start making decisions.

I’ll begin the decision process with the framework that I will use to build the site. Choosing the framework will steer many decisions throughout the process, so it’s essential to get it right. I am a big fan of NextJS and have only enjoyed it more every time I have used it. The documentation is excellent, and the framework is easy to use. As a UI developer that works in JS most of the day, it’s one of the two most popular static site generators in that language. It’s as easy to set up as create-react-app and has good documentation on getting things hosted. There is a good community around it, so if needed, you can most likely find someone who has solved any problems you may encounter. It checks all the boxes for me, so it seems like the logical choice. It has server-side rendering built-in, it’s fast, and I’m decently comfortable with it. It’s also something that I want to learn at a deeper level, and by using it, there should be a decent balance of speed in getting set up and the occasional learning how to do new things within the framework. If you aren’t familiar with it, I suggest taking a look at their docs, but in short, it is a framework for building web apps and sites in javascript with React. To me, if it’s going to be JS, it has to be React. So NextJS is the first decision. Not too bad. What’s next?

We can look at one of two things next. First, we need some way to manage the content. That means what will be included, how to organize it, and where to store it. Second, we need to decide what the site will look like and how the site’s content will be displayed to the user. These two things intertwine to an extent, so I feel like I need to think about them in parallel. Realistically the thing that both of these depend on is the structure of the content. What’s going to be on the blog? How much do I need to decide about that before I even start writing the content? This site is going to be my personal blog and a place to share learnings. Currently, that’s made up of 2 types of content, articles discussing topics and solutions to algorithm problems on Leetcode. There is presently no real organization of the content other than the two sections just mentioned. However, I could organize the algorithm solution pages by the languages I have used to solve a particular problem. I think something that I have had in the past that seemed valuable was tags or categories for the content. I plan to add that this time around. Let’s take a look at what the content is going to need. 

• Title - Every article, whether a general post or algorithm solution, will need a title. I will also use that title to create the slug or URL for the individual page.
• Date - General posts will need dates they are published to allow readers to know how up-to-date the content is. As JS and UI development is a fast-moving area, this seems most valuable to posts written on this topic.
• Content - Ok, I get it that I’m a developer, and I should use markdown. I should use markdown for everything. I should write birthday wishes to my family in markdown. I like markdown for a lot of things, and it’s great for a lot of things. We will need to revisit this part in a bit as I’m not sure that markdown will be the choice for me. The following two items are sub-items of content that need individual consideration.
• Code Blocks - Most of the articles that I write will be about code and will need some way to display that code nicely. There will also be code examples in multiple languages, so that needs to be a requirement as well. Prism is the standard that I know about for that on the web. 
• Images - There will be images in most if not all of the posts. I’ll need something that can handle doing that in a way that works for my designs.
• Relationships - There needs to be a way to handle relationships between some of the content types like categories or the kind of content it is.

Can I do all of that in markdown? Sure. Does it make sense to do it all in markdown? I’m not sure about that. Here is where the decisions start to get a bit harder. If I use markdown, I can keep all the content locally with the rest of the site code. I’ll need to figure out a way to customize the display of that content without a lot of parsing, or you start to lose the value of using markdown. I plan to use TailwindCSS for the blog, and it has an excellent typography plugin that would help out a lot with this. Here comes the counter for markdown, though. It’s called Prismic. It’s an online content management system (CMS) that has one distinguishing feature: most of the others I have looked at miss. It’s called slices and slice-machine. I have played around with it a bit in the past and am a beginner when it comes to using Prismic, but it does check all of the boxes I just listed. I can pair content with the components that will end up displaying it to the users. Add in the bonus that it will be a valuable tool to learn (I love learning), that there is a great community around it, that there is a very generous free tier that doesn’t skyrocket the minute you outgrow it, and the fact that the company seems to be great and willing to help out when you do run into issues, and my content decision is made. Decisions are getting harder. The last thing for this post is going to be hosting. 

Using NextJS means I should use Vercel, right? No decision is ever that easy. Would using Vercel make hosting my NextJS app/site easy? Yes. No doubt about it. It’s free for what I’m looking to do with it. So why is the decision hard? Netlify makes the decision hard. As I write this article, I am currently hosting it on Netlify. Which begs the question, what does Netlify have that Vercel doesn’t? Ecommerce on the free tier. What does Ecommerce have to do with this blog? Nothing. So why the question in making the decision? Most of the stuff that I do away from work is to learn. I can see myself opening an e-commerce site in the future and moving the products that I have on Etsy to it. So that’s why it’s going to be Netlify for hosting.

Decisions are hard. Decisions in software development can be crippling, even for stuff as simple as building a blog. To develop good software, you need to research decisions you need to make and be thoughtful as you make those decisions. But most importantly, you need to make them.