DEV Community: Tetsuro Mikami

I built five code generators to delete Go boilerplate

Tetsuro Mikami — Mon, 17 Aug 2026 03:43:22 +0000

Writing Go means writing the same mechanical code over and over: constructor wiring, conversions between domain types and API types, test fixtures, row scanning, message localization.

There are plenty of libraries that erase this with runtime reflection — but that moves failure to runtime and hides the behavior inside the library. So I went the other way: generate the code you were going to write anyway, and commit it to the repository.

go-kanna / kanna

Go code generators built on the standard library — DI, struct mapping, test fixtures, ORM. Each works on its own and emits plain Go with no runtime reflection.

kanna

Go code generators built on the standard library — DI, struct mapping, test fixtures, ORM, i18n. Each works on its own and emits plain Go with no runtime reflection.

Your structs are the source of truth. Point a generator at a package and it writes the code you would otherwise write by hand, so the output stays readable, debuggable, and free of anything to learn at runtime.

kanna-di

Wires a container struct from the providers it can find, and writes a plain constructor.

Install

go get -tool github.com/go-kanna/kanna/cmd/kanna-di

Use

A provider is a top-level function whose first result is a named type, a pointer to one, or an interface, optionally followed by an error. Nothing needs to be registered — kanna-di finds them by scanning the packages you point it at.

A container is a struct whose fields carry a di tag.

package app
//go:generate go tool kanna-di

…

View on GitHub

The output is ordinary Go. No reflection, no round-trips through interface{} — it shows up in code review and git diff, and you can step through it in a debugger.

Tool	What it does
`kanna-di`	generates constructor dependency wiring
`kanna-fixture`	generates test fixtures with every field filled
`kanna-mapper`	generates domain ↔ wire type conversion functions
`kanna-orm`	generates type-safe queries, row scanning, and relations
`kanna-i18n`	generates typed message constructors with translations embedded

All five install as independent go tools, so you can use just one. The input is the same for all of them: the struct declarations and struct tags you already have. Nothing gets registered anywhere.

Here is what each one does, shown with actual generated output.

kanna-di — constructor wiring

What it does: looks at a container struct's fields, finds the functions that can build them, and writes a constructor that calls them in dependency order.

A provider is "a package-level function whose first return value is a named type, a pointer to one, or an interface" (a trailing error is fine). No registration — it scans the packages you point it at.

// app/app.go
package app

//go:generate go tool kanna-di ./...

type DB struct{}

func NewDB() *DB { return &DB{} }

type User struct{ db *DB }

func NewUser(db *DB) User { return User{db: db} }

type Container struct {
    User User `di:""`
}

go generate ./... writes di_gen.go next to it:

// app/di_gen.go
// Code generated by kanna. DO NOT EDIT.

package app

// NewContainer initializes dependencies and constructs Container.
func NewContainer() *Container {
    db := NewDB()
    user := NewUser(db)

    return &Container{
        User: user,
    }
}

If anything in the dependency chain returns an error, the constructor returns one too and propagates it.

Whatever cannot be inferred, you spell out with tags on the container struct:

Tag	What it does
`di:""`	resolve from whichever provider returns the field's type
`di:"with=NewReadOnlyDB"`	name the provider to use
`di:"arg"`	make the dependency a constructor parameter
`di:"returns"`	make that type the constructor's return type (an interface works)
`di:"embed"`	take a struct as a parameter and offer its exported fields as resolution sources

A //kanna:container comment can also set the constructor name, the return type, and whether a MustNew* variant is generated.

When several providers match, it does not pick one silently — you get an error with the field's position and the list of candidates.

kanna-fixture — test fixtures

What it does: writes one constructor per struct in a package, with every field already filled. Tests state only the values they care about.

// model/user.go
package model

//go:generate go tool kanna-fixture -source ./model -destination ./fixture

type User struct {
    ID    int64
    Name  string
    Email string
    Age   int `fake:"{number:18,65}"`
}

// fixture/fixture_gen.go
// Code generated by kanna. DO NOT EDIT.

package fixture

func User(setters ...func(m *model.User)) model.User {
    m := model.User{
        ID:    gofakeit.Int64(),
        Name:  gofakeit.Name(),
        Email: gofakeit.Email(),
        Age:   gofakeit.Number(18, 65),
    }
    for _, s := range setters {
        s(&m)
    }
    return m
}

Using it:

u := fixture.User(func(m *model.User) { m.Email = "known@example.com" })

Every exported struct is covered — there is nothing to opt into. That is what keeps fixtures from falling behind the model. Field names drive the inference, so Email gets gofakeit.Email() and Name gets gofakeit.Name(); a tag like fake:"{number:18,65}" overrides it.

Types that need more than gofakeit, like uuid.UUID, are handled too — and if the destination module does not require the package yet, the generator says so.

Note: Generation is deterministic; the values are not. A test that needs the same data twice should call gofakeit.Seed(n) in TestMain.

kanna-mapper — domain ↔ wire conversions

What it does: writes the conversion functions between types you own and types you don't (protobuf output, DTOs). For fields Go cannot convert by itself, it calls a converter you registered once.

// lib/converters/converters.go
package converters

import "github.com/go-kanna/kanna/mapper"

func init() {
    mapper.Register(UUIDToString) // uuid.UUID → string
    mapper.RegisterE(uuid.Parse)  // string → uuid.UUID; this one can fail
}

Then name the pairs to map:

// mapper/gen.go
//go:generate go tool kanna-mapper -types=model.Employee:*employeev1.Employee -converters=../lib/converters
package mapper

The generated functions:

// mapper/mapper_gen.go
// EmployeeToEmployeev1 maps model.Employee to *employeev1.Employee.
func EmployeeToEmployeev1(src model.Employee) *employeev1.Employee {
    return &employeev1.Employee{
        Id:      converters.UUIDToString(src.ID),
        Name:    src.Name,
        Address: AddressToEmployeev1(src.Address),
    }
}

// EmployeeFromEmployeev1 maps *employeev1.Employee to model.Employee.
func EmployeeFromEmployeev1(src *employeev1.Employee) (model.Employee, error) {
    if src == nil {
        return model.Employee{}, nil
    }
    v1, err0 := uuid.Parse(src.GetId())
    if err0 != nil {
        return model.Employee{}, fmt.Errorf("map model.Employee.ID: %w", err0)
    }
    // ...
}

What you get:

Both directions. To and From are generated together
Nested structs are walked recursively (AddressToEmployeev1 gets called for you)
Error handling for fallible conversions, with the failing field named in the message
nil pointer handling, returning the zero value
Protobuf getters: src.GetId() is used where it exists
map:"-" excludes a field, map:"FieldName" names its counterpart

kanna-orm — type-safe queries

What it does: generates per-table query factories, row scanning, relation eager loading, and automatic timestamps from annotated model structs.

//kanna:table opts a struct in; everything else is inferred from the fields, and the orm tag overrides only where the inference disagrees with your schema.

// model/model.go
package model

//kanna:table
type User struct {
    ID        int       // primary key, by name
    Name      string    // column "name"
    Email     string    `orm:"email_address"` // explicit column name
    CreatedAt time.Time // set automatically on create
    Posts     []Post    `orm:"has_many,foreign_key:user_id"`
}

//kanna:table
type Post struct {
    ID     int
    UserID int
    Title  string
    User   *User `orm:"belongs_to,foreign_key:user_id"`
}

//go:generate go tool kanna-orm -source ./model -destination ./query

Using it:

db := orm.New(sqlDB, orm.MySQL) // or orm.PostgreSQL

users, err := query.Users(db).Where("name LIKE ?", "A%").OrderBy("id").All(ctx)
posts, err := query.Posts(db).Preload("User").All(ctx)

err = db.Transaction(ctx, func(tx orm.Querier) error {
    return query.Users(tx).Create(ctx, &model.User{Name: "Alice"})
})

What you get:

A factory returning orm.Query[T] per table
Row scanning generated for you (no more lining up rows.Scan arguments)
Relations — has_many / has_one / belongs_to / many_to_many, eager loading via Preload, plus Join / LeftJoin
Timestamps — CreatedAt / UpdatedAt are recognized by name and set automatically
MySQL and PostgreSQL, with placeholder and upsert differences absorbed by the runtime
Transactions — query code takes an orm.Querier, so it reads the same inside and outside a transaction

The query builder, dialects, and transactions live in the orm/ runtime; the generated code is plain Go on top of it.

Note: The destination must be a different package from the models. Generating into the model package means one stale output can make the models themselves stop compiling.

kanna-i18n — typed messages

What it does: generates a typed constructor per message from a directory of locale files — and embeds the translations into the output, so nothing is read or parsed at runtime.

One file per language, named by its BCP 47 tag:

# locales/en.yaml
greeting: "Hello!"
hello: "Hello, {name}!"
items_count:
  plural:
    one: "You have {count} item."
    other: "You have {count} items."
total_price: "Total: {price:number}"
user:
  not_found: "User not found."

//go:generate go tool kanna-i18n

With the defaults, that one line reads locales/ and writes messages/i18n_gen.go:

// messages/i18n_gen.go
// Hello returns the "hello" message.
func Hello(name string) i18n.Message {
    return i18n.Message{Key: "hello", Args: []i18n.Arg{
        {Name: "name", Value: name},
    }}
}

No setup on the calling side:

en := messages.Localizer(language.English)
fmt.Println(en.Localize(messages.Hello("World")))

What you get:

Placeholders become parameters. {name} produces Hello(name string); forgetting one is a compile error
Plurals. A {count} parameter following CLDR plural categories — languages like Japanese, which only have other, are handled correctly
Locale-aware number formatting. {price:number} renders as 1.234,56 in German
Fallback, walking en-GB → en → the default language
Missing translations warn; structural mismatches fail. A key absent from the default language, a plural shape that differs, a parameter that does not match — those stop generation. A translation that is merely late is a warning, and falls back at runtime

Since the translations are embedded, there is no YAML to ship with your deploy.

Install

Take only what you need:

go get -tool github.com/go-kanna/kanna/cmd/kanna-di
go get -tool github.com/go-kanna/kanna/cmd/kanna-fixture
go get -tool github.com/go-kanna/kanna/cmd/kanna-orm

# the two with a runtime take two lines
go get -tool github.com/go-kanna/kanna/cmd/kanna-mapper
go get github.com/go-kanna/kanna/mapper

go get -tool github.com/go-kanna/kanna/cmd/kanna-i18n
go get github.com/go-kanna/kanna/i18n

mapper and i18n take two lines because the parts that depend on runtime values — the converter registry, and CLDR plural rules, number formatting, language fallback — live in a runtime package. The other three are complete with just the generated code.

Every generator has -check, so CI can verify the output is not stale:

go tool kanna-di -check ./...

Status

It is v0.0.1: tests and CI are in place, but tag and directive syntax may still move. Go 1.25+, MIT licensed.

Every generator has a runnable example under examples/ in the repository, and CI regenerates all of them on every run and fails on any diff — so the output you saw above is what the generators actually produce.

https://github.com/go-kanna/kanna

Dependency Injection in Go: How Much Is Enough for Web APIs?

Tetsuro Mikami — Wed, 24 Dec 2025 06:50:57 +0000

Dependency Injection (DI) in Go often sparks debates that feel disproportionate to the actual needs of most web APIs. Discussions quickly escalate to containers, lifecycles, scopes, and dynamic resolution—despite the fact that many services have a simple, static dependency graph resolved once at startup.

This article argues a straightforward position:

For a typical web API, compile-time dependency resolution is enough.

From there, we’ll look at why runtime DI frameworks tend to be overkill, why static approaches like wire already cover most needs, and why a field-tag-based generator can simplify things even further.

What most web APIs actually need

If we strip away abstractions, a large percentage of Go web APIs share the same characteristics:

Stateless request handling
Dependencies resolved once at startup
A mostly tree-shaped dependency graph
- config → database → repository → service → handler
No runtime rebinding of implementations

In this environment, DI is not about flexibility at runtime. It’s about wiring correctness and maintainability.

Runtime DI frameworks: powerful, but usually unnecessary

Frameworks such as fx / dig or generics-based containers like do shine when your application behaves like a framework itself:

modules register themselves dynamically
lifecycle hooks (start/stop) matter
plugins or optional components are loaded at runtime

For typical web APIs, however, these features often come with downsides:

additional APIs to learn and remember
runtime error surfaces for what is fundamentally static wiring
harder-to-follow control flow during startup

When dependencies are fixed and known ahead of time, runtime DI solves a problem you don’t really have.

Static wiring is already enough

If dependencies are static, resolving them at compile time or generation time is a natural fit.

This is where tools like wire enter the picture. They provide:

compile-time dependency resolution
no runtime container
plain Go code as output

For a normal web API, this model is already sufficient. You get safety, predictability, and zero runtime DI overhead.

So far, the conclusion is simple:

For most web APIs, static DI is enough.

Where wire starts to feel heavy

Wire’s design emphasizes explicitness:

provider functions
provider sets
injector functions per root

This explicitness can be valuable in some organizational contexts. But in day-to-day API development, it often turns into maintenance overhead:

provider sets need constant updates as the graph evolves
DI-specific files grow alongside business code
the wiring itself becomes something developers have to reason about

The static model is right—but the amount of ceremony is not always justified.

A lighter static model: field-tag-based generation

If your goal is still static wiring and generated constructors, but with less DI-specific code, a simpler model works well:

declare what you want in a container struct
let a generator resolve the graph
emit plain Go constructors

Conceptually:

type Container struct {
    Handler *UserHandler `inject:""`
}

The generated code is just Go:

func NewContainer() (*Container, error) {
    cfg := NewConfig()
    db, err := NewDatabase(cfg)
    if err != nil {
        return nil, err
    }
    svc := NewUserService(db)
    h := NewUserHandler(svc)
    return &Container{Handler: h}, nil
}

No runtime container. No provider sets. No reflection.

This is the idea behind injector, a field-tag-only DI code generator:

https://github.com/mickamy/injector

The link is intentionally placed here, after the argument is established, rather than as an upfront pitch.

Is there still a place for wire?

Wire can still make sense when:

provider sets are treated as a public composition API
explicit wiring boundaries are a deliberate design goal
DI graphs are reviewed and curated as first-class artifacts

In other words, wire’s strengths are organizational and process-driven.

If your project doesn’t need that level of explicitness, wire becomes harder to justify.

Practical takeaway

Runtime DI (fx/dig, do)
- Powerful, but often overkill for standard web APIs
Static DI (wire)
- Sufficient for most APIs, but verbose
Static + minimal (injector)
- Same guarantees, less ceremony

For the common case—stateless web APIs with stable dependency graphs—static wiring is enough.

And if you can keep that wiring static and reduce the amount of DI-specific code you maintain, that’s an even better outcome.

Closing

Dependency Injection doesn’t need to be a framework-level decision for most Go web APIs. It’s a startup detail.

Resolve dependencies once. Generate plain Go code. Keep the wiring boring.

If wire already feels sufficient—but a bit heavy—the field-tag-based approach is a natural next step.

In that sense, injector is not a radical alternative.

It’s simply asking:

If static DI is enough… why not make it simpler?

Dependency Injection in Go, Reduced to Field Tags

Tetsuro Mikami — Thu, 18 Dec 2025 01:47:08 +0000

Dependency Injection (DI) in Go often feels heavier than it should be.

Once a project grows, you start seeing patterns like:

Large provider sets
Dedicated wiring files (for tools like wire)
Initialization order that humans must carefully maintain
DI-specific code spreading across the codebase

Over time, the amount of code written for DI itself can rival the actual business logic.

I wanted to see how far DI could be simplified in Go.

That experiment became injector.

The Core Idea

All dependency injection is declared using struct field tags.

Nothing else.

No provider sets.
No DSL.
No runtime reflection.

The container declares what is injected.
Providers declare how values are constructed.

The Container

A container is just a struct. Fields marked with the inject tag are managed by injector.

type Container struct {
    UserService service.UserService `inject:""`
}

The inject tag is intentionally minimal:

It is a marker only
It carries no configuration by default
It simply means “this field is injected by injector”

Providers

A provider is any top-level function that returns a value.

func NewUserService(db infra.Database) service.UserService {
    return &userService{DB: db}
}

Rules are simple:

The function must be top-level (no receiver)
Parameters are dependencies
The return value is the provided type

Injector discovers providers automatically via static analysis.

Generated Code

Running the generator:

injector generate ./...

Produces plain Go code:

func NewContainer() *Container {
    cfg := NewDatabaseConfig()
    db := NewDatabase(cfg)
    user := NewUserService(db)

    return &Container{
        UserService: user,
    }
}

There is no runtime magic.
The generated code is readable, debuggable, and type-safe.

Interface-First by Default

Injector works naturally with interfaces.

type UserService interface {
    Register(name, password string) error
}

func NewUserService(db infra.Database) UserService {
    return &userService{DB: db}
}

The container exposes only interfaces.
Concrete implementations remain private.

This keeps application boundaries clean without adding DI-specific abstractions.

Handling Multiple Providers

If multiple providers return the same type, injector requires an explicit choice.

type Container struct {
    _ config.DatabaseConfig `inject:"provider:NewPrimaryDatabaseConfig"`
    UserService service.UserService `inject`
}

A blank (_) field:

Does not expose the dependency
Declares a provider override
Applies globally within the container

Provider selection remains centralized and explicit.

Why Field Tags?

Go structs already represent dependency lists.

Adding extra configuration layers often makes DI harder to reason about, not easier.

By limiting DI declarations to field tags:

Dependencies are visible at a glance
Configuration stays local
The mental model stays small

DI should be infrastructure, not the focus of the codebase.

Status

Injector is intentionally small and opinionated.

The current goal is not feature breadth, but clarity:

Marker-based containers
Provider-based resolution
Compile-time dependency graphs

Future ideas exist, but they can wait until real-world usage drives them.

DEV Community: Tetsuro Mikami

I built five code generators to delete Go boilerplate

go-kanna / kanna

Go code generators built on the standard library — DI, struct mapping, test fixtures, ORM. Each works on its own and emits plain Go with no runtime reflection.

kanna

kanna-di

Install

Use

kanna-di — constructor wiring

kanna-fixture — test fixtures

kanna-mapper — domain ↔ wire conversions

kanna-orm — type-safe queries

kanna-i18n — typed messages

Install

Status

Dependency Injection in Go: How Much Is Enough for Web APIs?

What most web APIs actually need

Runtime DI frameworks: powerful, but usually unnecessary

Static wiring is already enough

Where wire starts to feel heavy

A lighter static model: field-tag-based generation

Is there still a place for wire?

Practical takeaway

Closing

Dependency Injection in Go, Reduced to Field Tags

The Core Idea

The Container

Providers

Generated Code

Interface-First by Default

Handling Multiple Providers

Why Field Tags?

Status

Links