Building a personal web service in Go, TDD Style: Part 1 - Motivations

There are a lot of different ways to spend your free time. How exactly did I end up building a personal web service in Go for fun?

More often than not, I am developing a personal project outside of work. While it can sometimes be challenging or stressful, I feel incomplete if I go too long without doing something creative. Before I learned to program, making music was my favorite way to express myself. After learning to code in Java for work, it was not long before I released a game on Steam using Unity and C#. Roze Blud, the game I released last year, was a nearly 4 year project. Drained of coding energy after the release, I ended up getting pretty good at competitive Street Fighter III - 3rd Strike. After bouncing around a few different projects, I started feeling the itch to do something technical, again.

Perhaps I was motivated a bit by imposter syndrome, career-wise. I felt a deficit of knowledge around cloud technologies like Kubernetes and Google Cloud Platform. I wanted to thoroughly understand unit testing and test-driven development (TDD). I do not have a computer science degree - in fact, I only ever took one programming class, after I graduated, at Boston University. I never intended to pursue a degree or anything, but just one course really rounded out my understanding of web applications, and I got to take this really cool mugshot ID photo.

That class, 10 years ago now, was the last time I built a web application from the ground up, “full-stack”, as they say. I decided to do it again, this time for my own growth and entertainment.

Why choose Go?

I love coding in Go. It is a fairly new language, and it is really great for building high-performance web applications. As a statically typed and compiled programming language, mismatched data and syntax problems are exposed before you can start running your application. This can be really advantageous over choosing a scripting language like Python, which I love equally, but for different reasons.

Go is especially great in the way it treats errors. Unlike in other languages where errors are “raised” by a function, in Go, a function returns an error, if applicable. Let us look at an example below:

 
func getArtist(id int) (Artist, error) {
	artist, err := repository.Get(id)
	if err != nil {
		return nil, err
	}

	return artist, nil
}

Here, the getArtist function takes an ID as an argument, and returns both an Artist struct and an error. If there is no issue, the error returned will be nil. If there is an issue, the error returned will be populated by the repository that returned the error, and the Artist will be nil.

This forces the programmer to always be thinking of errors and how to handle them. When issues arise, it can be a lot easier to figure out what went wrong, and these errors can be anticipated and handled gracefully.

What to build?

I still needed to figure out what problem my web service was going to solve! In the business world, you would normally have this figured out first. In my mission to learn, I decided to answer that question as a second step.

I started reviewing some past projects to see if any of them could be retrofitted into a web service. I wrote a command-line tool in Python to search IMDB’s public data sets, and for a bit this was my first choice. But after further consideration, I realized this was going to be more or less recreating IMDB’s existing application, but stripped down. I decided to look elsewhere.

I eventually settled on enhancing my “artist tracker”. Some time ago, I realized that because of my reliance on YouTube for playing music, lack of physical media and lack of digital music files, I end up forgetting which bands and artists I really like. So, I started building a list of the artists I like in a comma-separated file, and the desktop Google Drive application syncs this file to the cloud with each edit (via Notepad++ on my Windows desktop computer). This works OK, but naturally, there are issues. It is not terribly convenient. It is a bit awkward. There is no validation, so you can have issues like duplicate artists. As is, the process lacks the potential for enhancement. So, I decided to turn this artist tracker into my very own web service.