Posts

Numerous architectural models (Clean Architecture, Hexagonal, Onion, Domain‑Driven Design) present different terminology and slightly different structure, yet they converge on a single principle: Place business rules in their own layer. This inner layer is variously called entities, core, domain model, or business‑logic layer. I will refer to it as the domain layer. Without it, engineers must guess which mutations are legal and every feature starts with code‑base archaeology. A fictionalized crypto example The scenario below is distilled from common industry issues; the company, schema, and code are illustrative. ...

If you, like me, like to keep your code clean, then you probably need to do many refactors. I work in a monorepo with many services and this gives me a lot of flexibility for how to refactor code. I’ve done this many times over the years and I’ve found that breaking up refactors into incremental steps is key to completing them. Trying to do everything at once might seem faster, but I’ve seen too many refactors stall for months, unable to merge. Here’s how to be successful with your next refactor. ...

Tempts is my temporal Go SDK wrapper that enables safer usage of Temporal when writing workflows in Go. I’ve been using Tempts successfully for new code, but I found it difficult to migrate existing code that uses positional arguments rather than a single input object. The new version of Tempts makes this migration easy and provides an easy way to move away from positional arguments after migrating to Tempts. The problem with positional arguments Positional arguments are when your workflow or activity’s function signature looks like func(ctx context.Context, param1 string, param2 string) rather than func(ctx context.Context, params ParamType). The single input object pattern makes it easier to add and remove input parameters. With positional arguments, you can add parameters only to the end and can’t remove any without creating a new activity/workflow name. This is why Tempts originally didn’t support positional arguments at all. ...

When writing Go code, you have a lot of freedom in how you organize things, but there are some common pitfalls to avoid. One of them is what I’m calling the crab pattern. I’ve made this mistake plenty of times and always regretted it. The crab pattern happens when your code structure creates unnecessary dependencies. One side of the crab represents the importers of a central package and the other side represents the dependencies of a central package. This often happens when you group code by techincal similarity instead of what it actually does. The consequence is that if you need one part of the code, you end up pulling in everything else, which leads to a bloated, hard-to-manage dependency graph. ...

Introduction Let’s talk about global state in programming. We’ve all made excuses for using it, but there are better ways. Here, we’ll address some common excuses and show why avoiding global state is a game-changer. Common Excuses for Using Global State “I’ll use this code only in this specific way.” Code often outgrows its initial purpose, leading to unexpected issues. “It’s just the logger, though!” Even a logger can introduce hidden dependencies and headaches. ...

Are you using Temporal and writing workflows in Go using their Go SDK? If so, I have something for you. Otherwise feel free to skip this blog post. I created a type-safe wrapper around the Temporal Go SDK called tempts. It helps you avoid many common mistakes when working with Temporal workflows. The native SDK is powerful and flexible. Although this wrapper sacrifices some power and flexibility, it offers safety through its opinionated design. ...

There are three other packages already that implement data loaders in go, but after using them for a while, I wasn’t happy and decided to write my own. But why? Let’s start with “what’s a data loader?” It’s a pattern popularized by facebook in their dataloader javascript package. A data loader synchronizes multiple calls to fetch the same type of data (let’s say a user) by different keys (user IDs) and blocks the callers until “enough” of them have made a request. Then it dispatches all requests together as one batch request for multiple keys. This can turn N database calls into one. This is very useful when writing graphql code. ...

I recently taught myself HTMX, and I’m excited to see its growth because it revives an old idea that the world has forgotten: hypermedia.. Hypermedia was behind the original growth of the internet and, through HTMX it might be able to bring a new level of efficiency and productivity to a world tired of JavaScript single page applications and 10MB web pages. It’s promoted as a way to make back-end developers more productive by learning a little bit of front-end. I have some concerns about it that I hope to be addressed over time, but let’s start by looking at what it is. ...

I just published a blog post on the Anchorage Digital Engineering blog on the somewhat controversial topic of using code vs infrastructure to solve problems. You can learn where I stand by reading the original article here!

While attempting to extend the slog package in many different ways, I kept coming back to this idea that, at some point, I have to write a slog.Handler. I don’t have a need for high performance, and I just need an easy way to extend my logger to do additional things at the same time as logging. That’s why I created slogevent. This Go package makes extending slog as simple as writing a function that handles log entries. Here’s how you would write your custom log handling with slogevent: ...