I recently got a DevOps job that mostly involves writing a new backend system in Go completely from scratch. Here's what I learned having never actually used it in production, knowing it mostly just from personal projects.

1. You (probably) should use a web framework

At the start, we decided to try simply sticking with Go's http library and a simple routing library - mux.

However, I quickly ran into real-life, production problems:

• Recovery middleware - for logging & silently handling panics in handler's code.
• Logging - I wanted some solution that would print information about each request, including body params, auth tokens, etc. (for debugging purposes).
• Better error handling - I wanted the errors to still be JSON responses with an error message and code.
• Other commonly-used middleware - including JWT auth and CORS.

I had two options; implement solutions to the above problems myself, use different 3rd party libraries for each problem, or pick a web framework that already does most (if not all) of these things.

I eventually decided to use the Echo web framework. With almost 20k GitHub stars, a pretty active community, and great documentation I thought it was a great tool for the job.

I also found there to be a little less boilerplate when it comes to writing the apps in echo (mainly when parsing a json body, writing errors, and manually setting headers), leading to improved code readability.

However the real difference in productivity will be noticed when you have slightly more complex endpoints. You'll often run into cases where you need to validate certain JSON fields, and you'll want meaningful error messages describing what's wrong. If you want to do that without any library, your code will quickly become much harder to read:

2. You NEED a good code structure

Go web frameworks (or go in general) don't enforce any particular file structure. If you ever used something like ASP.NET/ASP.NET Core, you'll know what I'm talking about when I say that some frameworks are tightly structured and many things are done implicitly by convention rather than explicitly specified.

The thing about Go is that it's really easy to skip learning about structuring your code and make it a hard to read+maintain mess. If you still don't know what I'm talking about, here's an example of a (bad) Go endpoint I wrote a while back:

Do you see what I mean? It's quite likely that the in total the "better" way will contain more lines in total after adding all the CreateUser and CreateAgency methods, but… It will be much easier to understand, reuse, debug, and modify later on as each method will have a single purpose. If you haven't already, I highly recommend you have a look at the following resources for a good code structure: