What should a modern Go dependency injection framework look like?

Community
1

Go DI has always been a trade-off.

Runtime DI frameworks provide a convenient API, but they rely on reflection and discover dependency problems during application startup.

Compile-time DI frameworks avoid those problems, but some APIs become verbose and less ergonomic.

I have been exploring a different approach:

dig — compile-time dependency injection for Go with an Fx-style API and Wire-style code generation.

Repository:
https://github.com/shanjunmei/dig

The main design goals are:

  • dependency graph resolution during go generate

  • zero runtime reflection

  • zero runtime dependency after code generation

  • generated code is plain Go

  • minimal API: Build, Provide, Supply, Invoke, Module

Example:

func InitApp() func(context.Context) error {
    return dig.Build(
        dig.Provide(NewConfig),
        dig.Provide(NewDatabase),
        dig.Invoke(StartServer),
    )
}

After generation, the application does not depend on a DI runtime.

Some design questions I would like feedback on:

  1. Do you prefer compile-time DI or runtime DI in large Go projects?

  2. Is avoiding reflection an important advantage in practice?

  3. Are there DI patterns from Wire/Fx/custom solutions that should be preserved?

  4. What API choices would make a Go DI library feel natural?

The goal is not to create another DI library for its own sake, but to explore what a more Go-like DI design could look like.

Feedback and criticism are welcome.