In this chapter we covered a lot of ground. We learned different techniques for gracefully shutting down programs using signaling channels, which is especially important when our code has some work to do before it can exit. We saw that deferring the reporting of fatal errors at the start of our program can give our other deferred functions a chance to execute before the process ends.
We also discovered how easy it is to interact with MongoDB using the mgo
package, and how to use BSON types when describing concepts for the database. The bson.M
alternative to map[string]interface{}
helps us keep our code more concise, while still providing all the flexibility we need when working with unstructured or schemaless data.
We learned about message queues and how they allow us to break apart the components of a system into isolated and specialized micro-services. We started an instance of NSQ by first running the lookup daemon nsqlookupd
, before running a single nsqd
instance and connecting them together via a TCP interface. We were then able to publish votes to the queue in twittervotes
, and connect to the lookup daemon to run a handler function for every vote sent in our counter
program.
While our solution is actually performing a pretty simple task, the architecture we have put together in this chapter is capable of doing some pretty great things.
twittervotes
and counter
programs to run on the same machine—as long as they can both connect to the appropriate NSQ, they will function as expected regardless of where they are running.twittervotes
program learns of interesting tweets, there will always be somewhere to send the data.