In my previous blog posts, I shared with you how I built this blog using 

. In this post, I'll share with you how to set up the continuous integration and deployment (CI/CD) for a blog, which enables you to automate the build and deployment process. This is especially useful when you're working with a blog that uses a CMS because you can automate new builds when you update your content!

 is a cloud hosting platform that provides a simple and easy way to deploy web applications. It supports many Git integrations but I personally prefer GitHub. This allows you to trigger a new build and deploy whenever you push changes to the repository.

Add your using whichever Git provider you prefer.

Manage your environment variables. In my case, there are a few API keys that I want to keep out of version control so I use Netlify's environment variable features.

Set up your custom domain, if applicable.

Netlify automatically deploys the blog whenever you push changes to the repository.

I use Netlify for most of my projects these days. To be honest I am not even aware of the pricing because everything I have used it for thus far has been free of charge. It is affordable, has great settings and integrations, and is very quick to use. I definitely recommend checking it out if you have not yet.

Sanity provides a webhook API that sends a request to a provided URL whenever a dataset changes. This webhook can be used to trigger a new build of your app which is particularly useful for blogs.

To set up the webhook, I followed these steps:

In Netlify, add a new build hook and copy the URL.

Configure the build hook settings, such as the branch to deploy, the environment variables to use, and the build command to run.

In Sanity, create a webhook that points to the Netlify endpoint.

Paste the URL from Netlify in the webhook configuration in Sanity.

Sanity automatically triggers a new build whenever a dataset changes.

With this simple set up, everytime you update content through your CMS (Sanity), it will trigger a redploy of your app on Netlify. 

In the first section you created a deployment for the blog. This deployment utilizes Netlify and triggers a rebuild and deploy whenever the Git repository is updated. In the second section, you set up a webhook so that your CMS can communicate with the hosting service and trigger a rebuild when the associated content changes. This setup truly employs the power of Next and automation so that all you need to do to update the website is commit code updates or change the blog's content. 

I intentionally kept this post brief so some concepts were glossed over. Hopefully this still helps you get started and, as always, please feel free to leave feedback if you have questions or would like me to cover anything else in detail.

In my previous blog posts, I shared with you how I built this blog using Next and Sanity. In this post, I'll share with you how to set up the continuous integration and deployment (CI/CD) for a blog, which enables you to automate the build and deployment process.

DIY Blog Part 4: Continuous Integration and Delivery

Welcome to part three of this series where I will be talking about how I added comments to my blog. Why are comments worth adding? I think the most obvious part is engagement. Let's say you have a blog that has ads or some other form or revenue generation. The longer you have people on the page and interacting with your content, the more likely they are to click an ad or otherwise increase your revenue. That being said, I personally have other reasons. I don't have any monetization on this blog - that isn't really the purpose of it. To me, comments provide a chance to interact and form some sort of community. I've always really appreciated the tech community and I want to contribute to that culture. I think being able to comment on posts helps that. We can teach each other new things, correct any mistakes, and overall just grow as individuals together.

All that being said, I knew I wanted comments on my blog, but at first, I truly had no idea where to start. I narrowed down my options to a custom-built solution, 

Deep down inside, I wanted to go this route. There’s always a sort of satisfaction that you get from building your own tool like this. I'm sure I could pull together some simple CRUD for creating comments, maybe add threading as a nice feature. But before I settled with this idea, I wanted to see what other options were available to me.

Disqus definitely came up in most of my searches and I quickly realized I didn't want to build my own comment system anymore. With sign-on integrations, moderation, and basic comment features out of the box, the idea of building a basic version of that on my own seemed less and less logical. On top of that, Disqus is also hosted, so I wouldn't need to spin up any databases to manage the comment data. The only downside I could see was that due to all of the features, Disqus does have a pricing tier. At the time of writing, the basic (free) tier has the core features and any amount of total daily page views, but is ad-supported. Going up a tier to the Plus tier for $11 per month removes ads and supports up to 3 websites, but interestingly caps daily page views at 50,000. There is also a Pro tier at $105 a month, as well as a Business tier with custom pricing. These all seem like decent options, but I still wanted to see all the options out there.

Finally, that is where Utterances came in. Utterances is built using GitHub issues as the backend. Essentially, any given page with comments on it is given its own issue on a GitHub repository of your choice. I actually quite like this option because it is so simple to use while still looking and feeling high quality. The only downside I can see is that one needs a GitHub account to actually participate with the comments, but given the nature of this blog and how popular GitHub is, I am okay with this downside. Needless to say, this is the option I went with (check it out below!).

Setting up Utterances is actually quite easy. First, you will need to create a public repository on GitHub which will be used for the comments. Next, add the Utterances 

 and configure it to have access to the repository you created. You can give it access to all repositories or a select number — I personally went with the latter. Next, configure your desired settings on the 

 and simply copy and paste the provided script into your code. That’s it!

Generally speaking, there are many different ways to enable comments on your website. I have created custom solutions, but these require much more effort to build out all of the features that the solutions I have discussed in this post have by default. Ultimately, it is up to you based on your project’s needs. Feel free to leave a comment below if you have any questions or would like me to provide a more in-depth guide to Utterances.

Welcome to part three of this series where I will be talking about how I added comments to my blog.

DIY Blog Part 3: Comments

In my previous blog post I discussed Sanity, the headless CMS I am using to manage the posts on this blog. Now that that is out of the way, we can talk about how I have built the website itself to actually, you know, display those blog posts. After all, a headless CMS isn’t very useful without a head. In my case, the head will be powered by NextJS. Let’s get started.

Next is a React framework that provides a great developer experience (more on that later) and quick load times - especially when you have many static pages with data that can be retrieved ahead of time. Doesn’t that sound like I am just describing a blog?

I’ve begun to really enjoy using Next even without needing the fast load times. It has great features out of the box, particularly built-in, file-based routing. If there’s one thing that many developers dread about using React (other than state-management), it is routing. With Next, you can simply organize your website’s page structure using the structure of the files in your project. This does limit you to needing a structure that fits with that sort of organization, but realistically that is not a huge limitation.

On top of the straightforward file-based routing, Next also supports dynamic routing. For example, let’s say you have a folder called “posts” and in that folder you have an index.js and a 

 route. Any route that follows the pattern 

 file. Each of those files can simply export a functional component which is what will be rendered when those routes are used. For dynamic routing, the component 

 exports will be given postId as a prop with the value provided in the route. So in the example given, the value of 

 would be “123” which can be used however you wish.

The other feature that Next provides which is particularly useful for blogs is the ability to query for data before a page is built. Basically the way this works is you define a function called 

 if you are doing this on a dynamic route page so that Next knows what routes it will end up creating. Next will create a page for each dynamic route that it retrieves (

) before the page is built and also get the data each page requires (

). For a blog, that would mean retrieving the blog post based on the dynamic path (”123” in the previous example) and also retrieving all of the blog posts and creating dynamic paths for each. Here’s a more specific example using the file structure from before:

 function retrieves all of the appropriate blog posts first and then “populates” the paths with the retrieved ids so that going to those paths will actually correspond with a blog post. Then, for each of those paths which received a postId from the 

 to get that specific blog post and hand that data off to the 

 component’s props. This setup allows Next to build a page for every blog post ahead of time rather than at page load. When the app is built and deployed, all of the blog posts will be retrieved and have pages built for them. This is awesome because each page will be quick to load. The downside is that adding or updating a blog post would require the entire project to be rebuilt. For smaller sites this is not a huge problem but fortunately for larger sites Next already has a solution called Incremental Static Regeneration which you can learn more about in 

Similar to my previous post about Sanity, this is not intended to be a full tutorial for NextJS. My main goal is to give you a taste of what it can do and how I used it to set up this blog. Hopefully you learned something or maybe you were even inspired to start a blog of your own. Either way thanks for reading and feel free to comment or reach out to me if you have any questions. I’ll see you in the next post.

In my previous blog post I discussed Sanity, the headless CMS I am using to manage the posts on this blog. Now that that is out of the way, we can talk about how I have built the website itself to actually, you know, display those blog posts. 

DIY Blog Part 2: NextJS

If you're reading this, you are most likely either a developer or someone interested in software development. One thing that often connects us all is the desire to build something ourselves rather than rely on something prebuilt. The irony of this is that we typically build things for others to use, and we use plenty of prebuilt things to build our own things, but that is all besides the point.

In the spirit of doing it myself, I decided to build this blog myself rather than use something like Medium, Dev.to, or Wordpress. What's smarter than building a blog and then using the process of building it as content for said blog? Let's get started.

There are a few different steps to building your own blog with many different paths you can take. The first step for me was to choose a content management system (CMS) to manage the data for the blog. There are many great headless CMS options out there so my advice would be to do some research on each and see what works best for you. I'd like to revisit the topic and add some of my personal opinions on each but that is outside the scope of this post.

A "headless" CMS refers to a type of content management system where the backend is all that is provided for you. Often, a headless CMS will come with a dashboard where you can manage the data. The key part is that since only the backend is provided, you'll need to roll your own frontend. This means you have complete control over the presentation of your application - a blessing or a curse depending on your needs.

. Sanity is a pretty straightforward service to use. Some features include a hosted data management tool called Sanity Studio, a 

 for interacting with the data in your frontend, and a 

 (graph relational object query) based query language. I chose Sanity because

honestly I just wanted to try something new and different

I enjoy the developer experience they offer

The first thing you need to do in order to get started with Sanity is to create an account. Once you do that, you can download their CLI and follow the 

 to get a studio started on your local machine. The studio is where you interact with your datasets and also model out the data you will be storing. Sanity offers a few templates so I started with the blog template and made a few adjustments to the included schemas so that they better fit my needs. All in all the set up was pretty easy. A few points to keep in mind:

Sanity Studio is its own fully customizable application. That means you can change its functionality as dramatically or minimally as you see fit.

Being it’s own application, you can decide to use an independent git repository just for the application or you can make one large repository to contain both the frontend and the studio. In my case, I decided to use a separate repository for the studio since I am not planning on needing to make many changes to the studio after it is initially set up.

It might prove useful to use two different datasets, one for your production data and one for dev/local/testing data. You can do this by adding the following entries to your 

 within the studio project. More information can be found 

Sanity Studio now has a new major version (v3). The 

 file is replaced with a similar file so config will be slightly different if you are on v3. 

One thing that I really like about how this is all set up is that you do not need to store any keys or secrets in your project to run Sanity Studio. This is because once the app is running, you sign in through the app which handles all of the auth concerns.

That concludes the first part of this blog tutorial. Hopefully this can provide some guidance or inspiration when it comes to creating a blog of your own. A lot of the setup that needs to be done was not included in this write-up because the documentation on Sanity’s website does a great job already. Those docs can be found 

. As always, feel free to reach out if you have any questions. I’ll see you in the next post.

I decided to build this blog myself rather than use something like Medium, Dev.to, or Wordpress. What's smarter than building a blog and then using the process of building it as content for said blog? Let's get started.

DIY Blog Part 1: Sanity

Hey all and welcome to my blog. This is my first post on here so I wanted to talk about what I hope to achieve through blogging and some of my ideas for posts.

As I started off as a developer, I spent so many hours reading through documentation, blog posts, and guides on how to do various things related to software development. Now that I do software engineering professionally it isn't hard for me to look back and really appreciate all of the content I had access to — for free — on the internet. On top of the readily available content, everyone is so friendly. People are happy to help solve programming-related problems and just generally provide guidance for anyone, new or not.

One of my goals as a developer is to contribute to what I believe can be such a positive and friendly community of like-minded people. I love learning and mentorship just as much as I enjoy sitting down and solving a problem with code - to me they go hand in hand. As technology advances we must advance with it. That means we should constantly learn and be open to new ideas. Having that perspective will help us not only as professionals but also as individuals.

I have a few goals for this blog. I hope that it serves as an open place for ideas and collaboration to exist. I want this to be an outlet for my own ideas as I refine them. I'll probably post a lot of how-to's and guides but don't be mistaken: these are as much a learning experience for me as they are for any reader. I am by no means an expert so I hope to receive feedback and corrections whenever it seems like I miss the mark on something. Above all, I want this blog to be fun. Hopefully it will solve people's problems, motivate people to learn, or even inspire them to write about what they learn.

Categories

DIY Blog Part 4: Continuous Integration and Delivery

3 days ago

in Tutorials

DIY Blog Part 3: Comments

17 days ago

in Tutorials

DIY Blog Part 2: NextJS

17 days ago

in Tutorials

DIY Blog Part 1: Sanity

18 days ago

in Tutorials

Introductions are in order...

20 days ago

in Life & Musings