Learning how to structure an application in Go is hard. Not only are there a million different approaches out there, but everyone will tell you why you shouldn’t do X while rarely offering a better approach.
In reality, everything comes down to context. How big is your application? How are you deploying? How big is your team? Is your project open source? Do you have any conventions that your team prefers? How important are tests, and what coverage do you need? All of these factors and more will shape how you structure your application, because there truly isn’t a single “correct” way to structure an application. It depends entirely on your context.
Unfortunately knowing that context matters doesn’t always help. It still leaves the new Gopher wondering, “What structure is best for my context?”
The goal of this series is to explore application structure in Go. We will mostly be exploring this from a web application perspective, but most, if not all, of the information we cover will be useful regardless of what type of applications you are building.
We will start be examining why it is so hard for everyone to just agree on a universal structure, and then dive into a few various options for structuring your application and discuss when and why they can be useful. We will also discuss some pitfalls each has and why you may hear people telling you to avoid some of them (even though they are entirely feasible for many applications).
By the end I hope to leave you with enough information that you can start building with the confidence that you can learn and adapt as your project and team grows without feeling the need to start with a structure too complicated for your current needs.
The first thing we need to discuss is why it feels like this problem is solved in other languages and/or frameworks (eg Ruby on Rails uses MVC), but in Go this is still an unsolved problem. (Hint: It isn’t really as solved in other languages as you might believe.)
In this article we will discuss context, how other languages approach the application design problem, why they might take the approach they do, and what we can learn from it as we design our applications in Go.
A flat application structure is basically exactly what it sounds like. Rather than creating directories with packages in them, we instead opt to just put all of our code in a single package.
This is almost certainly the least hip way to layout your code, but I have found it to be insanely refreshing for many projects. It is reminiscent of my PHP days when I was just learning to code and I cared more about making the damn website work rather than how I was supposed to be coding.
It probably goes without saying, but a flat app structure won’t work forever. At some point your application is going to outgrow it. That said, it likely works much longer than you think, and this is typically one of the easiest structures to let evolve naturally as your application grows in complexity.
MVC has been around for a LOOONG time, but it is often discouraged in Go. It is my belief that MVC is actually a pretty good fit for Go, but it requires you to drop some preconceived notions about what MVC is and how it should be implemented.
In this article we not only look at what MVC is, but how to implement it effectively in Go. We will even look at package naming, mistakes to avoid, and by the end you will hopefully be ready to try out an MVC application in Go.
This series is actively being composed. The next article should be available around Oct 25th, 2019.
Sign up for my mailing list and I'll send you a FREE sample from my course - Web Development with Go. The sample includes three chapters from the book, and over 2.5 hours of screencasts.
You will also receive notifications when I release new articles, along with other freebies that I only share with my mailing list.
Jon Calhoun is a full stack web developer who also teaches about Go, web development, algorithms, and anything programming related. He also consults for other companies who have development needs. (If you need some development work done, get in touch!)
Jon is a co-founder of EasyPost, a shipping API that many fortune 500 companies use to power their shipping infrastructure, and prior to founding EasyPost he worked at google as a software engineer.
Jon's latest progress update: Writing Course Notes
Spread the word
Did you find this page helpful? Let others know about it!
Sharing helps me continue to create both free and premium Go resources.
Want to discuss the article?
©2018 Jonathan Calhoun. All rights reserved.