Why Go
I'd been writing JavaScript for most of my career. It's flexible, forgiving, and everywhere. But I kept hearing about Go — its simplicity, its speed, its opinionated approach to concurrency and error handling. I wanted to understand why people loved it so much.
Rather than following tutorials, I decided to learn by building real services. Not todo apps or calculators, but actual backend systems that handle data, talk to databases, and serve APIs. That's how Gooking was born. The name combines "Go" and "cooking," because I was cooking up Go services.
Starting with weather
The first service was a Weather API. CRUD operations for weather records, integration with OpenWeatherMap, and a PostgreSQL database for persistence. Simple on the surface, but it taught me a lot.
Go's error handling philosophy — where every error is explicit and must be dealt with — felt verbose at first. Coming from JavaScript's try-catch-and-hope approach, writing "if err != nil" on every other line felt tedious. But slowly I began to appreciate it. My code became more predictable. Bugs were caught at compile time instead of runtime.
Finding the architecture
The biggest lesson came when I restructured everything into a proper layered architecture. Handler, Service, Repository. Each layer with a clear responsibility. Dependency injection through constructors. No global variables. No shortcuts.
This pattern felt over-engineered for a personal project at first. But as I added the scraper service, the cron scheduler, and the GIS endpoints, the architecture paid for itself. Adding a new feature meant adding a method to each layer in sequence, and each piece was testable in isolation. The structure wasn't overhead. It was infrastructure.
Growing into a monorepo
As ideas accumulated — a bookmark manager, a webhook tester, an analytics dashboard — I needed a monorepo structure. Shared packages like database utilities and scheduling went into a common "pkg" directory, while each service lived in its own folder with its own entry point, migrations, and configuration.
The GIS Explorer became the second major feature. It started as a way to visualize regional data on interactive maps and grew into a rich frontend with D3.js. Adding backend endpoints to the existing Weather API service taught me about extending services without breaking existing functionality.
What I learned
Gooking taught me that the best way to learn a technology is to build something you genuinely care about. Go's philosophy of simplicity and explicitness changed how I think about code in any language. The microservices architecture taught me that good structure is an investment, not a tax.
The project is still growing. There are services I haven't built yet, features I haven't polished, and patterns I haven't explored. But that's the beauty of a learning project. It's never finished because you're never done learning.