11 Working with Larger Projects
Throughout this book, we have built several small applications to demonstrate various parts and patterns of the Go programming language. For the most part, these applications have been self-contained, relying on the standard library packages we explored in previous chapters and custom packages we wrote ourselves. In everyday development, however, this is rarely the case. Developers routinely use shared libraries to support their projects. Unlike the standard library, these external libraries are managed by individuals or small teams rather than undergoing a standardization process requiring community consensus.
Beyond external libraries, applications interact with external services through clients and APIs. Documenting and managing these dependencies can be challenging but is essential in most workflows.
In the chapter on Concurrency, we started an application that used an external dependency to parse RSS feeds. Now, we will build upon that foundation by creating a multi-module architecture that separates concerns and allows different components to evolve independently. We’ll explore packages, modules, and workspaces to keep our code organized and reusable. Specifically, we’ll separate our RSS reader into four modules: a shared domain module (domain model), a storage module (persistent implementation using bbolt), a REST API service, and a background worker that fetches feeds asynchronously.