When a team of Google coders looked out across the collection of computer languages in 2007, they saw hundreds of perfectly good tools for writing software but none that offered the right features for Google. That is, a language that supported building the Google vision of a galaxy of software packages working together in Google’s vast collection of servers.
Some languages were too focused on the lowest bit-banging levels of the stack. Others were too complex, larded with features that would only get in the way. The Google developers wanted a language that was simple enough to be learned in a few hours but just complex enough to handle the flow of information across the modern Internet.
The solution was Go, a language that will look familiar to programmers who were raised on C, Java, or JavaScript—in other words, just about every programmer. Go has just enough features to write some loops and coding blocks but none of the fancier ideas that take time to master. The built-in routines are optimized for getting data to and from the Internet. Everything else, no matter how clever, is left out.
Go is a great option for teams building applications based on microservice architectures because these constellations of services are just smaller versions of the galaxy that Google runs today. Your project may not offer email, maps, search, and countless other cloud services to the world, but it could still end up offering dozens of different smaller information services to the users. Each microservice project is just a micro—or maybe a nano—version of Google.
Google’s decision to open source Go was a wise one. The language has nurtured thousands of projects that offer the building blocks for your web project. This rich tradition makes it easier to work in parallel in other teams to create your own constellation.
Here are 20 of the most interesting open source projects for spinning up a web of Go microservices. From smaller toolkits focused on messaging, routing, error handling, or APIs to fuller frameworks for building MVC web apps, you’ll find an abundance of options for going micro with Go.
Beego
The Beego framework includes many of the standard extras like a full-featured router and an object-to-database mapper with CRUD operations pretty much ready to roll. A favorite of many Beego fans is the Bee tool, a fast and powerful command-line tool for building, updating, packaging, and deploying your application. The Bee tool will generate source code from templates and keep the database fresh.
Buffalo
Many of the microservices frameworks take you only so far. The Buffalo team needed something that could assemble all of the parts of a web application including some of the design of the application itself. They like to call it an “ecosystem” for a number of parts that can be installed together. If you want routing—and few wouldn’t—Buffalo will roll in the Gorilla/Mux project. If you need templates, Buffalo prefers Plush over the built-in Go mechanism. An extensive collection of database connection modules called Pop will help you turn database information into Go objects. You will also find standard approaches for connecting to databases, handling cookies, and accomplishing almost everything else you can imagine.
Cobra
Sometimes you just want a command-line interface for your code. Cobra is ready to handle all of the standard features of a CLI so you don’t need to waste your time implementing code to look for —h or -help flags. If your microservices are going to respond to command-line invocations with lots of flags and other features, then you’ll want to integrate Cobra.
Docker
You can run your microservice code on any machine including some of the bare-metal boxes in that long forgotten server room in your office, but more and more folks are bundling up their code in Docker containers and sending those containers to the cloud. The small packages make it easier to juggle lots of different chunks of code—a valuable service when your vision for a microservice architecture commands you to create many small, independent blocks of code.
It’s worth mentioning that Docker is written in Go, although you’ll probably never use this fact when deploying Docker containers. The Docker community edition is open source, so you can monkey with it if you need to, but most likely you’ll just use Docker as a tool to deploy your own microservice genius. The real reason Go fans want to remember that Docker is written in Go is because Docker’s ubiquity is a strong statement of support for the language.
Echo
Echo is a minimalist framework, but it has many of the most important components for delivering the bits. The router will unpack URLs and turn the parts into parameters so you don’t need to parse them. Then you can mix in authentication, form parsing, compression, and sensible limits. You can concentrate on returning the right information from your function.
Errors
Sometimes the users of an API will pass bad parameters that need to be flagged. You can handle this yourself or you can pass it to Errors, a library that will automate much of the tracking to help with debugging. When an error occurs, Errors wraps it up with annotations that detail what went wrong and where.
Gin
In case the name doesn’t make it obvious, the Gin project is the next generation of the popular Martini framework. You might say that Gin throws away the extras and focuses on the ingredients that deliver the most oomph. Developers who have spent a good deal of time building Node.js applications for microservices will feel right at home. You create a microservice in Gin by instantiating an object and then attaching functions to handle particular invocations. Gin handles the routing and your functions provide the business logic. If you ignore a few punctuation marks, it even looks like Node.js code.
Ginkgo
Testing may be the most challenging area of microservice development. Ginkgo extends the built-in testing mechanism of the standard Go distribution with behavior-driven testing. The language for the tests offers a high-level mechanism for spelling out just what should come out of the functions or service. The results are typically evaluated with Ginkgo’s own Gomega matcher, though you can use a different matcher library if you like.
Ginkgo is a sophisticated framework with a wide variety of options for setting up the test data, running the tests, and tearing down the test data after the fact. The structure encourages you to describe the results and then let Ginkgo handle everything else.
Goa
If you’re a developer who worked with Ruby and the Praxis framework in the past or you’re just someone who appreciates the power and discipline of a design language, you’ll find plenty to like in Goa. You don’t write Go code per se. You write out a design spec for the API in the Goa DSL and then Goa turns it into the Go code that does the work. The DSL is optimized for microservice APIs and forces your design to conform to a standard architecture.
Gorilla
Another big collection of modules designed to deliver much of what you need very quickly is provided by the Gorilla project. Gorilla’s Mux router is used by many of the other frameworks because it’s so good. Many of the users immediately point to the websocket code as the main reason they adopted Gorilla.
Gotify
One of the challenges for synchronizing a group of microservices is setting up efficient message-passing nodes. Gotify is a simple server for sending and receiving messages, knitting together your collection of microservices with messages that persist. The most useful part may be the web interface that helps with debugging, a task that can be maddeningly difficult.
Hugo
Not many microservices can be built with a static site generator like Hugo, but it’s an option that’s worth considering when there are a limited number of answers to the repetitive queries. Hugo will spit out the answers once and then they can be served again and again. This is most useful when your answers are already delivered in HTML.
Kite
If you’re looking to build a more tightly controlled constellation of services with more than the usual amount of interaction between services, take a look at Kite. Kite was built to make the coordination of microservices communications a bit simpler. API calls from non-Kites enter through a websocket, then new messages are passed around using faster, lower-level socket connections (based on dnode). A service registry and authentication service called Kontrol sits in the middle. If you’re going to be swapping messages frequently, coordinating many actions, adding this layer of interconnection between the different servers can make everything faster.
Logrus
Keeping track of the data flowing in and out of your API and the errors it might generate usually means writing log files. The process can be as simple as writing a single line of data to an open file, but it usually makes sense to embrace a full framework for logging with all of the extra features and structure. Logrus provides formatters to standardize your output and make it much easier to automate any log file analysis later on. Don’t write your own quick-and-dirty logging code. Use a library like Logrus.
Nano
It doesn’t take much to set up a microservice. The Nano project is a wonderful example of simplicity. There aren’t much more than 200 lines of real code—and just a few more than 400 lines if you count the comments. Yet you can set up a microservice with just a few lines of your own code — a microservice that will encapsulate just the business logic needed to process a request. The framework has a few other nice touches, like a language-agnostic API structure, so your Go code can play well with any other services written in other languages. And then there’s a good testing process to embed your own local testing routines. There’s not much more, but that’s the point.
Negroni
Some people looked at Martini and decided to take it in a simpler direction. They stripped out the router and a few other bits to create Negroni, a very minimal tool that won’t do much more than serve up some standard files, handle your custom requests, recover from basic problems, and keep a log. If you want the extras, you can mix them in yourself. The Negroni team provides a long list of smaller projects that fit together with theirs.
Renderer
When you prepare your output, you’ll need to take the data and insert it in templates. Renderer is one project that offers a wide range of output formats (JSON, JSONP, XML, YAML, HTML, file) and a nice, fast and standard templating engine.
Revel
Revel borrowed a neat feature from the webpack world of Node.js that lets Revel act like an IDE, or at least the part of the IDE that constantly rebuilds your project whenever you make changes to the code. Once you press save, the framework senses the change, compiles the code, and, if there are no compile errors, starts the application. Thus the Revel server will automatically deploy changes to its code—ideal for developing on your desktop, and perhaps a bit too tempting for the code in production.
The framework itself is full-featured with all of the major and minor mechanisms found in the most feature-rich. That means templating, caching, validation, and filters that act on the data as it flows through the request pipeline. If you’re building a number of microservices, there’s a module system that allows you to share some of the MVC components between projects.
Testify
One of the simplest ways to employ classic assertion testing is with Testify, a Go project that also offers mocking tools for quickly testing individual parts of your grand collection of microservices. It only takes a few lines to write some basic tests and then check, automatically, if the code is returning the right response.
Tollbooth
When you first release your API, you want everyone in the world to call it. When your server melts down—or you look at your cloud hosting bills for elastic services—you change your mind. Tollbooth is a lightweight system for limiting incoming requests to a certain number per second. Cutting off demand at the front door reduces the demands on the microservices or databases down the pipeline, allowing you to keep everything running smoothly.
None
And by “None,” I mean no framework at all. You just start writing Go code from scratch without importing anything or instantiating some controlling object. It’s easy to create a microservice in Go because Go already has much of the basic code built in. This is why it’s possible to build frameworks like Nano with just a few hundred lines of code.
All of the work for listening on the sockets, unpacking the HTTP request, and more is done for you in one of the standard libraries that are part of the standard distribution. Sure, some framework can add some discipline or some features, but many times you won’t need it if you’re just writing a very basic microservice. All the “extras” just get in the way and that leads some Go developers to say that the code ends up becoming even more complex. If you’re just going to be listening on the wire and making a few basic decisions with the information coming in, you might be able to get by with nothing.