Application Design
Real-world SQL in Go: Part I
Regardless of whether you hate SQL or merely tolerate it, you're going to use it in a project at some point. Relational database structures don't always map well to application data structures but SQL's ubiquity means that it's the standard tool developers
Common CRUD Design in Go
Create, Read, Update, & Delete (CRUD) is the tech industry's bread-and-butter. You're familiar with it if you've spent any time doing application development. Many programming languages lean on frameworks to provide an opinionated structure for CRUD applications, but the Go community is notoriously anti-framework.
The Go Object Lifecycle
Despite such a simple language, Go developers have found a surprising number of ways to create and use objects. In this post we’ll look at a 3-step approach to object management—instantiation, initialization, & initiation. We’ll also contrast this with other methodologies for creating and using objects and
Failure is your Domain
Go’s paradox is that error handling is core to the language yet the language doesn’t prescribe how to handle errors. Community efforts have been made to improve and standardize error handling but many miss the centrality of errors within our application’s domain. That is, your errors are
Standard Package Layout
Vendoring. Generics. These are seen as big issues in the Go community but there’s another issue that’s rarely mentioned — application package layout. Every Go application I’ve ever worked on appears to have a different answer to the question, how should I organize my code? Some applications push
Structuring Applications in Go
For me, the hardest part of learning Go was in structuring my application. Prior to Go, I was working on a Rails application and Rails makes you structure your application in a certain way. “Convention over configuration” is their motto. But Go doesn’t prescribe any particular project layout or
