Structuring a Go Application

Become a Subscriber

Golang is one of the most popular languages growing amongst senior developers. With great concurrency, async, debugging and compilation baked in.. it’s truly a pleasure to work with. One of the most common issues I come across when working with other Go developers is that many of them struggle to architect an application. There are few easy to find and digest tutorials on the web. Combine the lack of teaching tools with a non-seasoned developer and you have a recipe for misuse and bad code. We hope to remedy that by teaching some basic principles that will help in a variety of applications.

Building a full stack web application with Go

We get it: you have worked with Rails, Laravel, or some other full-stack framework that does view rendering on the server side. Hell you may even be trendy and using meteor or node.js and simplifying your stack. Either way, you’re probably doing things in a non future-proof way. Server side rendering is easy, but that does not make it right. Neither do websockets for most applications despite the buzz.. Instead consider building an asynchronous API that powers your application. This will make your web app portable, should you consider a new interface like a mobile application. It will also make your app lightning fast, as you can make your application feel more dynamic or single page.

Our own, Jiran Dowlati can tell you from personal experience: templating in Go really sucks. The templating package is fine and robust for basic parsing, put if you were to implement a view hierarchy and rending solution like you might find in Rails, you will find yourself very frustrated and disappointed with the results. Instead you should consider using a javascript framework on the front-end to standardize your API requests. We love React with Flux, or Angular for this type of work. By doing things this way, you’ll enjoy writing the API bits in Go and keeping all of your view logic entirely on the front-end and much more portable should you want to change things up.

API’s are better with Go

Don’t take our word for it. Look at this post by parse: How We Moved Our API From Ruby to Go and Saved Our Sanity. Not only will you see significant performance gains by building your API in Go, but you will also enjoy and simplify the code over most languages. API’s really should be anti-framework too and thus we love Go for this reason also.

Building command line tools

It’s not as common of a practice any more it seems, as everyone loves bash scripting and using their own scripting language or w/e as a command line tool, but we are old school. Compiling a command line tool is more scaleable if you need to leverage that tool for cron jobs and the like.. is often times more secure and is definitely more portable. We love Go for this scenario too. Compilation in Go rivals any language we have seen, and has incredible systems support. Amongst all of the types of applications Go can be used for, system and network administration are definitely the most common. There aren’t a ton of recommendations we need to make for building command line tools other than sticking with Go packages. Don’t go off and write your own parsing package, or file system tool. Go is cross platform and the standard library should have more than enough to address any need you have. Default to scouring the documentation rather than reinventing the wheel.

Building mobile applications

This is actually the only bit we’re going to say to stay away from. While Go support is picking up for Android, and could eventually find parity with iOS, it’s too young at the time of this post. Unless you’re doing simple prototypes, we suggest staying away from the mobile frontier when developing with Go. Instead favor the more mature native implementations, until you see Android / iOS documentation actually reference building with Go on a granular level.