A reflection based dependency injection toolkit for Go

# :hammer_and_pick: dig [![GoDoc][doc-img]][doc] [![GitHub release][release-img]][release] [![Build Status][ci-img]][ci] [![Coverage Status][cov-img]][cov] [![Go Report Card][report-card-img]][report-card]

A reflection based dependency injection toolkit for Go.

### Good for:

* Powering an application framework, e.g. [Fx](https://github.com/uber-go/fx).
* Resolving the object graph during process startup.

### Bad for:

* Using in place of an application framework, e.g. [Fx](https://github.com/uber-go/fx).
* Resolving dependencies after the process has already started.
* Exposing to user-land code as a [Service Locator](https://martinfowler.com/articles/injection.html#UsingAServiceLocator).

## Installation

We recommend consuming [SemVer](http://semver.org/) major version `1` using
your dependency manager of choice.

```
$ glide get 'go.uber.org/dig#^1'
$ dep ensure -add "go.uber.org/dig@v1"
$ go get 'go.uber.org/dig@v1'
```

## Stability

This library is `v1` and follows [SemVer](http://semver.org/) strictly.

No breaking changes will be made to exported APIs before `v2.0.0`.

[doc-img]: http://img.shields.io/badge/GoDoc-Reference-blue.svg
[doc]: https://godoc.org/go.uber.org/dig

[release-img]: https://img.shields.io/github/release/uber-go/dig.svg
[release]: https://github.com/uber-go/dig/releases

[ci-img]: https://github.com/uber-go/dig/actions/workflows/go.yml/badge.svg
[ci]: https://github.com/uber-go/dig/actions/workflows/go.yml

[cov-img]: https://codecov.io/gh/uber-go/dig/branch/master/graph/badge.svg
[cov]: https://codecov.io/gh/uber-go/dig/branch/master

[report-card-img]: https://goreportcard.com/badge/github.com/uber-go/dig
[report-card]: https://goreportcard.com/report/github.com/uber-go/dig

## Stargazers over time

[![Stargazers over time](https://starchart.cc/uber-go/dig.svg)](https://starchart.cc/uber-go/dig)



Lightweight, generic & simple dependency injection (DI) container

Component-based development with dependency injection using reflections for Go developers

<div>
    <div align="center"><img src="https://avatars.githubusercontent.com/u/80048065?s=200&u=a95ef12cecad462ed24df9418a8464241301cc16"/></div>
    <div align="center">
        <a href="https://github.com/boot-go/boot/tags"><img alt="Commit tag" src="https://img.shields.io/github/v/tag/boot-go/boot"></a>
        <a href="https://github.com/boot-go/boot/actions/workflows/action.yml"><img src="https://github.com/boot-go/boot/actions/workflows/action.yml/badge.svg?branch=main" alt="github action"></a>
        <a href="https://htmlpreview.github.io/?https://gist.githubusercontent.com/boot-go/c77b22000b3e249510dfb4542847c708/raw/ae9b2e83e9a4adafed6da2160e40855f86ca58a8/cover.html"><img src="https://img.shields.io/endpoint?url=https://gist.githubusercontent.com/boot-go/c77b22000b3e249510dfb4542847c708/raw/test_coverage.json" alt="test coverage"></a>
        <a href="https://goreportcard.com/report/github.com/boot-go/boot"><img src="https://goreportcard.com/badge/github.com/boot-go/boot" alt="go report"></a>
        <a href="https://pkg.go.dev/github.com/boot-go/boot"><img src="https://pkg.go.dev/badge/github.com/boot-go/boot.svg" alt="Go Reference"></a>
        <a href="https://opensource.org/licenses/MIT"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="License: MIT"></a>
    </div>
</div>

**boot-go** accentuate [component-based development](https://en.wikipedia.org/wiki/Component-based_software_engineering) (CBD).

This is an opinionated view of writing modular and cohesive [Go](https://github.com/golang/go) code. It emphasizes the separation of concerns by loosely coupled components, which communicate with each other via methods and events. The goal is to support writing maintainable code on the long run by leveraging the well-defined standard library.

**boot-go** provided key features are:
- dependency injection
- configuration handling
- code decoupling

### Development characteristic
**boot-go** supports two different development characteristic. For simplicity reason, use the functions ```Register```, ```RegisterName```, ```Override```, ```OverrideName```, ```Shutdown``` and ```Go``` to register components and start **boot-go**. This is the recommended way, despite the fact that one global session is used.

But **boot-go** supports also creating new sessions, so that no global variable is required. In this case, the methods ```Register```, ```RegisterName```, ```Override```, ```OverrideName```, ```Shutdown``` and ```Go``` are provided to register components and start **boot-go**.

### Simple Example
The **hello** component is a very basic example. It contains no fields or provides any interface to interact with other components. The component will just print the _'Hello World'_ message to the console.
```go
package main

import (
	"github.com/boot-go/boot"
	"log"
)

// init() registers a factory method, which creates a hello component.
func init() {
	boot.Register(func() boot.Component {
		return &hello{}
	})
}

// hello is the simplest component.
type hello struct{}

// Init is the initializer of the component.
func (c *hello) Init() error {
	log.Printf("boot-go says > 'Hello World'\n")
	return nil
}

// Start the example and exit after the component was completed.
func main() {
	boot.Go()
}
```

The same example using a new session, which don't need any global variables.
```Go
package main

import (
	"github.com/boot-go/boot"
	"log"
)

// hello is the simplest component.
type hello struct{}

// Init is the initializer of the component.
func (c *hello) Init() error {
	log.Printf("boot-go says > 'Hello World'\n")
	return nil
}

// Start the example and exit after the component was completed.
func main() {
	s := boot.NewSession()
	s.Register(func() boot.Component {
		return &hello{}
	})
	s.Go()
}
```

### Component wiring
This example shows how components get wired automatically with dependency injection. The server component starts at ```:8080``` by default, but the port is configurable by setting the environment variable ```HTTP_SERVER_PORT```. 
```go
package main

import (
	"github.com/boot-go/boot"
	"github.com/boot-go/stack/server/httpcmp"
	"io"
	"net/http"
)

// init() registers a factory method, which creates a hello component
func init() {
	boot.Register(func() boot.Component {
		return &hello{}
	})
}

// hello is a very simple http server example.
// It requires the Eventbus and the chi.Server component. Both components
// are injected by the boot framework automatically
type hello struct {
	Eventbus boot.EventBus  `boot:"wire"`
	Server   httpcmp.Server `boot:"wire"`
}

// Init is the constructor of the component. The handler registration takes place here.
func (h *hello) Init() error {
	// Subscribe to the registration event
	h.Eventbus.Subscribe(func(event httpcmp.InitializedEvent) {
		h.Server.HandleFunc("/", func(writer http.ResponseWriter, request *http.Request) {
			io.WriteString(writer, "boot-go says: 'Hello World'\n")
		})
	})
	return nil
}

// Start the example and test with 'curl localhost:8080'
func main() {
	boot.Go()
}
```

### Component
Everything in **boot-go** starts with a component. They are key fundamental in the development and can be considered as an elementary build block. The essential concept is to get all the necessary components functioning with as less effort as possible. Therefore, components must always provide a default configuration, which uses the most common settings. As an example, a **http server** should always start using port **8080**, unless the developer specifies it. Or a postgres component should try to connect to **localhost:5432** when there is no database url provided.

A component should be _fail tolerant_, _recoverable_, _agnostic_ and _decent_.

| Facet           | Meaning                                       | Example                                                                                                                                                                         |
|-----------------|-----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| _fail tolerant_ | Don't stop processing on errors.              | A http request can still be processed, even when the metrics server is not available anymore.                                                                                   |
| _recoverable_   | Try to recover from errors.                   | A database component should try to reconnect after losing the connection.                                                                                                       |
| _agnostic_      | Behave the same in any environment.           | A key-value store component should work on a local development machine the same way as in a containerized environment.                                                          |
| _decent_        | Don't overload the developer with complexity. | Keep the interface and events as simple as possible. It's better to build three smaller but specific components then one general with increased complexity. Less is often more. |

### Configuration
Configuration values can also be automatically injected with arguments or environment variables at start time. The value from ```USER``` will be used in this example. If the argument ```--USER madpax``` is not set and the environment variable is not defined, it is possible to specify the reaction whether the execution should stop with a panic or continue with a warning.
```go
package main

import (
	"github.com/boot-go/boot"
	"log"
)

// hello is still a simple component.
type hello struct{
	Out string `boot:"config,key:USER,default:madjax"` // get the value from the argument list or environment variable. If no value could be determined, then use the default value `madjax`.
}

// init() registers a factory method, which creates a hello component and returns a reference to it.
func init() {
	boot.Register(func() boot.Component {
		return &hello{}
	})
}

// Init is the initializer of the component.
func (c *hello) Init() error {
	log.Printf("boot-go says > 'Hello %s'\n", c.Out)
	return nil
}

// Start the example and exit after the component was completed
func main() {
	boot.Go()
}

```


### boot stack
**boot-go** was primarily designed to build opinionated frameworks and bundle them as a stack. So every developer or company can choose to use the [default stack](https://github.com/boot-go/stack), a shared stack or rather create a new one. Stacks should be build with one specific purpose in mind for building a **microservice**, **ui application**, **web application**, **data analytics application** and so on. As an example, a **web application boot stack** could contain a http server component, a sql database component, a logging and a web application framework.


### Examples
More examples can be found in the [tutorial repository](https://github.com/boot-go/tutorial).


boot-go

A dependency injection framework based on components, allowing dynamic dependency replacement without duplicating code in tests

# ComponeGo Framework

[![Go Report Card](https://goreportcard.com/badge/github.com/componego/componego)](https://goreportcard.com/report/github.com/componego/componego)
[![Tests](https://github.com/componego/componego/actions/workflows/tests.yml/badge.svg?branch=master)](https://github.com/componego/componego/actions/workflows/tests.yml)
[![codecov](https://codecov.io/gh/componego/componego/branch/master/graph/badge.svg?token=W4CPM75389)](https://codecov.io/gh/componego/componego)
[![Go Reference](https://pkg.go.dev/badge/github.com/componego/componego.svg)](https://pkg.go.dev/github.com/componego/componego)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

![screenshot](./docs/mkdocs/theme/assets/images/social.png)

It is a framework for building applications based on components. These components can be used in multiple applications and are interchangeable.
This framework is used solely to initialize the application and does NOT affect the main loop of your application.
You can still use your favorite frameworks and libraries. We allow you to wrap them in components.

Components may depend on other components. They can be expanded or reduced based on your requirements.
Components are not microservices; they are folders that contain different functionalities.

The framework has very low coupling within its code. All entities are optional.

We provide the ability to use dependency injection, configuration, and error handling.
However, one of the framework's main features is that you can modify entities without changing the application code.
This allows you to create mocks for any part of your application without changing the code.

If your application is divided into components (modules), it further separates your code into different services and allows you to reuse it in other applications.
Of course, you don’t need to make components too small.

### Documentation

Introduction: [medium.com/@konstanchuk/25bfd16a97a9](https://medium.com/@konstanchuk/25bfd16a97a9).

Visit our website to learn more: [componego.github.io](https://componego.github.io/).

The documentation is up-to-date with the latest version of the framework.
Please update your version to [the latest](https://github.com/componego/componego/releases).

### Examples

You can find some examples [here](./examples).

A typical application of this framework looks like [this](./examples/url-shortener-app/internal/application/application.go).

### Skeleton

You can quickly create a basic application in several ways:
```shell
curl -sSL https://raw.githubusercontent.com/componego/componego/master/tools/create-basic-app.sh | sh
```
or
```shell
wget -O - https://raw.githubusercontent.com/componego/componego/master/tools/create-basic-app.sh | sh
```
On Windows, you can run the commands above with Git Bash, which comes with [Git for Windows](https://git-scm.com/download/win).

### Contributing

We are open to improvements and suggestions. Pull requests are welcome.

### License

The source code of the repository is licensed under the [Apache 2.0 license](./LICENSE).
The core of the framework does not depend on other packages.


componego

A dependency injection service container for Go projects

[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
[![GoDoc](https://pkg.go.dev/badge/github.com/NVIDIA/gontainer/v2)](https://pkg.go.dev/github.com/NVIDIA/gontainer/v2)
![Test](https://github.com/NVIDIA/gontainer/actions/workflows/go.yml/badge.svg)
[![Report](https://goreportcard.com/badge/github.com/NVIDIA/gontainer/v2)](https://goreportcard.com/report/github.com/NVIDIA/gontainer/v2)

# Gontainer

Simple but powerful dependency injection container for Go projects!

<p align="center"><img src="splash.png" width="600"/></p>

## Features

- 🎯 Automatic dependency injection based on function signatures.
- ✨ Super simple interface to register and run services.
- 🚀 Lazy service creation only when actually needed.
- 🔄 Lifecycle management with proper cleanup in reverse order.
- 🤖 Clean and tested implementation using reflection and generics.
- 🧩 No external packages, no code generation, zero dependencies.

## Quick Start

The example shows how to build the simplest app using service container.

```go
package main

import (
    "context"
    "log"
    "github.com/NVIDIA/gontainer/v2"
)

// Your services.
type Database struct{ connString string }
type UserService struct{ db *Database }

func main() {
    err := gontainer.Run(
        context.Background(),
        
        // Register Database.
        gontainer.NewFactory(func() *Database {
            return &Database{connString: "postgres://localhost/myapp"}
        }),
        
        // Register UserService - Database is auto-injected!
        gontainer.NewFactory(func(db *Database) *UserService {
            return &UserService{db: db}
        }),
        
        // Use your services.
        gontainer.NewEntrypoint(func(users *UserService) {
            log.Printf("UserService ready with DB: %s", users.db)
        }),
    )
    
    if err != nil {
        log.Fatal(err)
    }
}
```

## Examples

* [Console command example](./examples/01_console_command/main.go) – demonstrates how to build a simple console command.
  ```
  12:51:32 Executing service container
  12:51:32 Hello from the Hello Service Bob
  12:51:32 Service container executed
  ```
* [Daemon service example](./examples/02_daemon_service/main.go) – demonstrates how to maintain background services.
  ```
  12:48:22 Executing service container
  12:48:22 Starting listening on: http://127.0.0.1:8080
  12:48:22 Starting serving HTTP requests
  ------ Application was started and now accepts HTTP requests -------------
  ------ CTRL+C was pressed or a TERM signal was sent to the process -------
  12:48:28 Exiting from serving by signal
  12:48:28 Service container executed
  ```
* [Complete webapp example](./examples/03_complete_webapp/main.go) – demonstrates how to organize web application with multiple services.
  ```
  15:19:48 INFO msg="Starting service container" service=logger
  15:19:48 INFO msg="Configuring app endpoints" service=app
  15:19:48 INFO msg="Configuring health endpoints" service=app
  15:19:48 INFO msg="Starting HTTP server" service=http address=127.0.0.1:8080
  ------ Application was started and now accepts HTTP requests -------------
  15:19:54 INFO msg="Serving home page" service=app remote-addr=127.0.0.1:62640
  15:20:01 INFO msg="Serving health check" service=app remote-addr=127.0.0.1:62640
  ------ CTRL+C was pressed or a TERM signal was sent to the process -------
  15:20:04 INFO msg="Terminating by signal" service=app
  15:20:04 INFO msg="Closing HTTP server" service=http
  ```
* [Transient service example](./examples/04_transient_services/main.go) – demonstrates how to return a function that can be called multiple times to produce transient services.
  ```
  11:19:22 Executing service container
  11:19:22 New value: 8767488676555705225
  11:19:22 New value: 5813207273458254863
  11:19:22 New value: 750077227530805093
  11:19:22 Service container executed
  ```

## Installation

```bash
go get github.com/NVIDIA/gontainer/v2
```

Requirements: Go 1.21+

## Core Concepts

### 1. Define Services

Services are just regular Go types:

```go
type EmailService struct {
    smtp string
}

func (s *EmailService) SendWelcome(email string) error {
    log.Printf("Sending welcome email to %s via %s", email, s.smtp)
    return nil
}
```

### 2. Register Factories

Factories create your services. Dependencies are declared as function parameters:

```go
// Simple factory.
gontainer.NewFactory(func() *EmailService {
    return &EmailService{smtp: "smtp.gmail.com"}
})

// Factory with dependencies - auto-injected!
gontainer.NewFactory(func(config *Config, logger *Logger) *EmailService {
    logger.Info("Creating email service")
    return &EmailService{smtp: config.SMTPHost}
})

// Factory with a cleanup callback.
gontainer.NewFactory(func() (*Database, func() error) {
    db, _ := sql.Open("postgres", "...")
    
    return db, func() error {
        log.Println("Closing database")
        return db.Close()
    }
})
```

### 3. Run Container

```go
err := gontainer.Run(
    context.Background(),
    gontainer.NewFactory(...),
    gontainer.NewFactory(...),
    gontainer.NewEntrypoint(func(/* dependencies */) {
        // application entry point
    }),
)
```

## Advanced Features

### Resource Cleanup

Return a cleanup function from your factory to handle graceful shutdown:

```go
gontainer.NewFactory(func() (*Server, func() error) {
    server := &http.Server{Addr: ":8080"}
    go server.ListenAndServe()
    
    // Cleanup function called on container shutdown.
    return server, func() error {
        ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
        defer cancel()
        return server.Shutdown(ctx)
    }
})
```

### Optional Dependencies

Use when a service might not be registered:

```go
gontainer.NewFactory(func(metrics gontainer.Optional[*MetricsService]) *API {
    api := &API{}
    
    // Use metrics if available
    if m := metrics.Get(); m != nil {
        api.metrics = m
    }
    
    return api
})
```

### Multiple Dependencies

Get all services implementing an interface:

```go
type Middleware interface {
    Process(http.Handler) http.Handler
}

gontainer.NewFactory(func(middlewares gontainer.Multiple[Middleware]) *Router {
    router := &Router{}
    for _, mw := range middlewares {
        router.Use(mw)
    }
    return router
})
```

### Dynamic Resolution

Resolve services on-demand:

```go
gontainer.NewEntrypoint(func(resolver *gontainer.Resolver) error {
    // Resolve service dynamically.
    var userService *UserService
    if err := resolver.Resolve(&userService); err != nil {
        return err
    }
    
    return userService.DoWork()
})
```

### Transient Services

Create new instances on each call:

```go
// Factory returns a function that creates new instances.
gontainer.NewFactory(func(db *Database) func() *Transaction {
    return func() *Transaction {
        return &Transaction{
            id: uuid.New(),
            db: db,
        }
    }
})

// Use the factory function.
gontainer.NewEntrypoint(func(newTx func() *Transaction) {
    tx1 := newTx()  // new instance
    tx2 := newTx()  // another new instance
})
```

## API Reference

### Module Functions

Gontainer module interface is really simple:

```go
// Run creates and runs a container with provided options.
func Run(ctx context.Context, opts ...Option) error

// NewFactory registers a service factory.
func NewFactory(fn any) Option

// NewService registers a pre-created service.
func NewService[T any](service T) Option

// NewEntrypoint registers an entrypoint function.
func NewEntrypoint(fn any) Option
```

### Factory Signatures

**Factory** is a function that creates one service. It can have dependencies as parameters,
and can optionally return an error and/or a cleanup function for the factory.

**Dependencies** are other services that the factory needs which are automatically injected.

**Service** is a user-provided type. It can be any type except untyped `any`, context and `error`.


```go
// The simplest factory.
func() *Service

// Factory with dependencies.
func(dep1 *Dep1, dep2 *Dep2) *Service

// Factory with error.
func() (*Service, error)

// Factory with cleanup.
func() (*Service, func() error)

// Factory with cleanup and error.
func() (*Service, func() error, error)
```

### Built-in Services

Gontainer provides several built-in services that can be injected into factories and functions.
They provide access to container features like context, dynamic resolution, and invocation.

```go
// context.Context - The factory's context.
func(ctx context.Context) *Service

// *gontainer.Resolver - Dynamic service resolution.
func(resolver *gontainer.Resolver) *Service

// *gontainer.Invoker - Dynamic function invocation.
func(invoker *gontainer.Invoker) *Service
```

### Special Types

Gontainer provides special types for optional and multiple dependencies.

```go
// Optional[T] - Optional dependency declaration.
type Optional[T any] struct{}
func (o Optional[T]) Get() T

// Multiple[T] - Multiple services of the same interface.
type Multiple[T any] []T
```

## Error Handling

Gontainer provides typed errors for different failure scenarios:

```go
err := gontainer.Run(ctx, factories...)

switch {
case errors.Is(err, gontainer.ErrFactoryReturnedError):
    // Factory returned an error.
case errors.Is(err, gontainer.ErrEntrypointReturnedError):
    // Entrypoint returned an error.
case errors.Is(err, gontainer.ErrNoEntrypointsProvided):
    // No entrypoints were provided.
case errors.Is(err, gontainer.ErrCircularDependency):
    // Circular dependency detected.
case errors.Is(err, gontainer.ErrDependencyNotResolved):
    // Service type not registered.
case errors.Is(err, gontainer.ErrFactoryTypeDuplicated):
    // Service type was duplicated.
}
```

## Contributing

We welcome contributions! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

## License

Apache 2.0 – See [LICENSE](LICENSE) for details.

## Documentation for `v1`

Documentation for the previous major version `v1` is available at [v1 branch](https://github.com/NVIDIA/gontainer/tree/v1).


gontainer

A YAML-based Dependency Injection container for GO. It supports dependencies' scopes, and auto-detection of circular dependencies. Gontainer is concurrent-safe

[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)
[![Go Reference](https://pkg.go.dev/badge/github.com/gontainer/gontainer.svg)](https://pkg.go.dev/github.com/gontainer/gontainer)
[![Build Status](https://github.com/gontainer/gontainer/actions/workflows/tests.yaml/badge.svg?branch=main)](https://github.com/gontainer/gontainer/actions?query=workflow%3ATests)
[![Coverage Status](https://coveralls.io/repos/github/gontainer/gontainer/badge.svg?branch=main)](https://coveralls.io/github/gontainer/gontainer?branch=main)
[![Go Report Card](https://goreportcard.com/badge/github.com/gontainer/gontainer)](https://goreportcard.com/report/github.com/gontainer/gontainer)
[![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=gontainer_gontainer&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=gontainer_gontainer)

# Gontainer

A Dependency Injection container for GO. Gontainer is concurrent-safe, supports scopes and offers hot swapping.

If the code generation is not for you, [see](https://github.com/gontainer/gontainer-helpers/blob/main/container/README.md) how to manually build a container.

Using the bootstrapping technique, Gontainer uses itself to compile its dependencies.
1. [Configuration](internal/gontainer)
2. [Usage](internal/cmd/runner_builder.go)

## Docs

1. Documentation
   1. [Version](docs/VERSION.md)
   2. [Meta](docs/META.md)
   3. [Parameters](docs/PARAMETERS.md)
   4. [Services](docs/SERVICES.md)
   5. [Decorators](docs/DECORATORS.md)
2. [Interface](docs/INTERFACE.md)

## Installation

**homebrew**

```bash
brew install gontainer/homebrew-tap/gontainer
```

**go install**

```bash
go install github.com/gontainer/gontainer@latest
```

**Manual compilation**

```bash
git clone git@github.com:gontainer/gontainer.git
cd gontainer
GONTAINER_BINARY=/usr/local/bin/gontainer make
```

## TL;DR

**Describe dependencies**

Either YAML or GO

<details>
  <summary>YAML</summary>

File `gontainer/gontainer.yaml`:

```yaml
meta:
  pkg: "gontainer"
  constructor: "New"
  imports:
     mypkg: "github.com/user/repo/pkg"

parameters:
  appPort: '%envInt("APP_PORT", 9090)%' # get the port from the ENV variable if it exists, otherwise, use the default one

services:
  endpointHelloWorld:
    constructor: "mypkg.NewHelloWorld"

  serveMux:
    constructor: '"net/http".NewServeMux'                       # serveMux := http.NewServerMux()
    calls:                                                      #
      - [ "Handle", [ "/hello-world", "@endpointHelloWorld" ] ] # serveMux.Handle("/hello-world", gontainer.Get("endpointHelloWorld"))

  server:
    getter: "GetServer"           # func (*gontainer) GetServer() (*http.Server, error) { ... }
    must_getter: true             # func (*gontainer) MustGetServer() *http.Server { ... }
    type: '*"net/http".Server'    # 
    value: '&"net/http".Server{}' # server := &http.Server{}
    fields:                       #
      Addr: ":%appPort%"          # server.Addr = ":" + gontainer.GetParam("appPort")
      Handler: "@serveMux"        # server.Handler = gontainer.Get("serverMux")
```

**Compile it**

```bash
gontainer build -i gontainer/gontainer.yaml -o gontainer/container.go

# it can read multiple configuration files, e.g.
# gontainer build -i gontainer/gontainer.yaml -i gontainer/dev/\*.yaml -o gontainer/container.go
```
</details>

<details>
<summary>GO</summary>

File `gontainer/gontainer.go`:

```go
package gontainer

import (
   "net/http"
   "os"

   "github.com/gontainer/gontainer-helpers/v3/container"
   "github.com/user/repo/pkg"
)

type gontainer struct {
   *container.SuperContainer
}

func (g *gontainer) MustGetServer() *http.Server {
   raw, err := g.Get("server")
   if err != nil {
      panic(err)
   }
   return raw.(*http.Server)
}

func New() *gontainer {
   sc := &gontainer{
      SuperContainer: container.NewSuperContainer(),
   }

   sc.OverrideParam("serverAddr", container.NewDependencyProvider(func() string {
      if v, ok := os.LookupEnv("APP_PORT"); ok {
         return ":" + v
      }
      return ":9090"
   }))

   endpointHelloWorld := container.NewService()
   endpointHelloWorld.SetConstructor(pkg.NewHelloWorld)
   sc.OverrideService("endpointHelloWorld", endpointHelloWorld)

   serveMux := container.NewService()
   serveMux.SetConstructor(http.NewServeMux)
   serveMux.AppendCall(
      "Handle",
      container.NewDependencyValue("/hello-world"),
      container.NewDependencyService("endpointHelloWorld"),
   )
   sc.OverrideService("serveMux", serveMux)

   server := container.NewService()
   server.SetConstructor(func() *http.Server {
      return &http.Server{}
   })
   server.SetField("Addr", container.NewDependencyProvider(func() (interface{}, error) {
      return sc.GetParam("serverAddr")
   }))
   server.SetField("Handler", container.NewDependencyService("serveMux"))
   sc.OverrideService("server", server)

   return sc
}
```
</details>

**Voilà!**

File `main.go`:

```go
package main

import (
	"github.com/user/repo/gontainer"
)

func main() {
	c := gontainer.New()
	s := c.MustGetServer()

	err := s.ListenAndServe()
	if err != nil {
		panic(err)
	}
}
```


gontainer/gontainer

A generics based dependency injection framework for Go

<div align="center">

[![Build and Test](https://github.com/go-kod/kod/actions/workflows/go.yml/badge.svg)](https://github.com/go-kod/kod/actions/workflows/go.yml)
[![GitHub Release](https://img.shields.io/github/v/release/go-kod/kod)](https://github.com/go-kod/kod/releases)
[![Go Report Card](https://goreportcard.com/badge/github.com/go-kod/kod)](https://goreportcard.com/report/github.com/go-kod/kod)
[![Code Cov](https://codecov.io/github/go-kod/kod/graph/badge.svg?token=FKCHAE6M2R)](https://codecov.io/github/go-kod/kod)
[![Go Reference](https://pkg.go.dev/badge/github.com/go-kod/kod.svg)](https://pkg.go.dev/github.com/go-kod/kod)
[![GitHub License](https://img.shields.io/github/license/go-kod/kod)](https://github.com/go-kod/kod/blob/main/LICENSE)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

[**English**](./README.md) •
[**简体中文**](./README_CN.md) |
[**Examples**](./example_test.go) •
[**Template**](https://github.com/go-kod/kod-mono) •
[**Extention**](https://github.com/go-kod/kod-ext)

</div>

# Kod

Kod stands for **Killer Of Dependency**, a generics based dependency injection framework for Go.

> Although it seems that most Go enthusiasts dislike dependency injection framework, many companies that widely use Go for their development projects have open-sourced their own dependency injection frameworks. For example, Google has open-sourced Wire, Uber has open-sourced Fx, and Facebook has open-sourced Inject. This is truly a strange phenomenon.

![kod](/assets/kod.excalidraw.png)

## Feature

- **Component Based**: Kod is a component-based framework. Components are the building blocks of a Kod application.
- **Configurable**: Kod can use TOML/YAML/JSON files to configure how applications are run.
- **Testing**: Kod includes a Test function that you can use to test your Kod applications.
- **Logging**: Kod provides a logging API, `kod.L`. Kod also integrates the logs into the environment where your application is deployed.
- **OpenTelemetry**: Kod relies on OpenTelemetry to collect trace and metrics from your application.
- **Hooks**: Kod provides a way to run code when a component start or stop.
- **Interceptors**: Kod has built-in common interceptors, and components can implement the following methods to inject these interceptors into component methods.
- **Interface Generation**: Kod provides a way to generate interface from structure.
- **Code Generation**: Kod provides a way to generate kod related codes for your kod application.

## Installation

```bash
go install github.com/go-kod/kod/cmd/kod@latest
```

If the installation was successful, you should be able to run `kod -h`:

```bash
A powerful tool for writing kod applications.

Usage:
  kod [flags]
  kod [command]

Available Commands:
  callgraph        generate kod callgraph for your kod application.
  completion       Generate the autocompletion script for the specified shell
  generate         generate kod related codes for your kod application.
  help             Help about any command
  struct2interface generate interface from struct for your kod application.

Flags:
  -h, --help      help for kod
  -t, --toggle    Help message for toggle
  -v, --version   Help message for toggle

Use "kod [command] --help" for more information about a command.
```

## Step by Step Tutorial

In this section, we show you how to write Kod applications. To install Kod and follow along, refer to the Installation section. The full source code presented in this tutorial can be found here.

### Components

Kod's core abstraction is the component. A component is like an actor, and a Kod application is implemented as a set of components. Concretely, a component is represented with a regular Go interface, and components interact with each other by calling the methods defined by these interfaces.

In this section, we'll define a simple hello component that just prints a string and returns. First, run `go mod init hello` to create a go module.

```bash
mkdir hello/
cd hello/
go mod init hello
```

Then, create a file called `main.go` with the following contents:

```go
package main

import (
    "context"
    "fmt"
    "log"

    "github.com/go-kod/kod"
)

func main() {
    if err := kod.Run(context.Background(), serve); err != nil {
        log.Fatal(err)
    }
}

// app is the main component of the application. kod.Run creates
// it and passes it to serve.
type app struct{
    kod.Implements[kod.Main]
}

// serve is called by kod.Run and contains the body of the application.
func serve(context.Context, *app) error {
    fmt.Println("Hello")
    return nil
}
```

`kod.Run(...)` initializes and runs the Kod application. In particular, `kod.Run` finds the main component, creates it, and passes it to a supplied function. In this example, `app` is the main component since it contains a `kod.Implements[kod.Main]` field.

```bash
go mod tidy
kod generate .
go run .
Hello
```

## FUNDAMENTALS

### Components

Components are Kod's core abstraction. Concretely, a component is represented as a Go interface and corresponding implementation of that interface. Consider the following `Adder` component for example:

```go
type Adder interface {
    Add(context.Context, int, int) (int, error)
}

type adder struct {
    kod.Implements[Adder]
}

func (*adder) Add(_ context.Context, x, y int) (int, error) {
    return x + y, nil
}
```

Adder defines the component's interface, and adder defines the component's implementation. The two are linked with the embedded `kod.Implements[Adder]` field. You can call `kod.Ref[Adder].Get()` to get a caller to the Adder component.

#### Implementation

A component implementation must be a struct that looks like:

```go
type foo struct{
    kod.Implements[Foo]
    // ...
}
```

It must be a struct.
It must embed a `kod.Implements[T]` field where T is the component interface it implements.
If a component implementation implements an `Init(context.Context) error` method, it will be called when an instance of the component is created.

```go
func (f *foo) Init(context.Context) error {
    // ...
}

func (f *foo) Shutdown(context.Context) error {
    // ...
}
```

#### Lazy Initialization

Components can be lazily initialized by embedding a `kod.LazyInit` field in the component implementation, 
which will be initialized when the component is first used, instead of when the application starts.

Simple demo below:

```go
type foo struct {
    kod.Implements[Foo]
    kod.LazyInit
}
```

#### Interceptors

Kod has built-in common interceptors, and components can implement the following methods to inject these interceptors into component methods:

```go
func (f *foo) Interceptors() []interceptor.Interceptor {
    return []interceptor.Interceptor{
        kmetric.New(),
        ktrace.New(),
    }
}
```

#### Interfaces

Interface can be generated automatically by kod tool.

```go
//go:generate kod struct2interface .
```

### Config

#### WithConfig

Kod uses config files, written in TOML, to configure how applications are run. A minimal config file, for example, simply lists the application name:

```toml
[kod]
name = "hello"
```

A config file may also contain component-specific configuration sections, which allow you configuring the components in your application. For example, consider the following `Greeter` component.

```go
type Greeter interface {
    Greet(context.Context, string) (string, error)
}

type greeter struct {
    kod.Implements[Greeter]
}

func (g *greeter) Greet(_ context.Context, name string) (string, error) {
    return fmt.Sprintf("Hello, %s!", name), nil
}
```

Rather than hard-coding the greeting "Hello", we can provide a greeting in a config file. First, we define an `options` struct.

```go
type greeterOptions struct {
    Greeting string
}
```

Next, we associate the `options` struct with the greeter implementation by embedding the `kod.WithConfig[T]` struct.

```go
type greeter struct {
    kod.Implements[Greeter]
    kod.WithConfig[greeterOptions]
}
```

Now, we can add a Greeter section to the config file. The section is keyed by the full path-prefixed name of the component.

```toml
["example.com/mypkg/Greeter"]
Greeting = "Bonjour"
```

When the Greeter component is created, Kod will automatically parse the Greeter section of the config file into a `greeterOptions` struct. You can access the populated struct via the `Config` method of the embedded `WithConfig` struct. For example:

```go
func (g *greeter) Greet(_ context.Context, name string) (string, error) {
    greeting := g.Config().Greeting
    if greeting == "" {
        greeting = "Hello"
    }
    return fmt.Sprintf("%s, %s!", greeting, name), nil
}
```

You can use TOML struct tags to specify the name that should be used for a field in a config file. For example, we can change the `greeterOptions` struct to the following.

```go
type greeterOptions struct {
    Greeting string `toml:"my_custom_name"`
}
```

#### WithGlobalConfig

Also, we can use the `kod.WithGlobalConfig` struct to read the whole config from the config file.

```go
type greeter struct {
    kod.Implements[Greeter]
    kod.WithGlobalConfig[greeterOptions]
}
```

Now, we can add global configuration to the config file based on the `greeterOptions` struct.

```toml
greeting = "Bonjour"
```

### Testing

#### Unit Test

Kod includes a `Test` function that you can use to test your Kod applications. For example, create an `adder_test.go` file with the following contents.

```go
package main

import (
    "context"
    "testing"

    "github.com/go-kod/kod"
)

func TestAdd(t *testing.T) {
     kod.RunTest(t, func(ctx context.Context, adder Adder) {
         got, err := adder.Add(ctx, 1, 2)
         if err != nil {
             t.Fatal(err)
         }
         if want := 3; got != want {
             t.Fatalf("got %q, want %q", got, want)
         }
     })
}
```

Run go test to run the test. `kod.RunTest` will create a sub-test and within it will create an Adder component and pass it to the supplied function. If you want to test the implementation of a component, rather than its interface, specify a pointer to the implementing struct as an argument. For example, if the `adderImpl` struct implemented the Adder interface, we could write the following:

```go
kod.RunTest(t, func(ctx context.Context, adder *adderImpl) {
    // Test adder...
})
```

#### Benchmark

You can also use `kod.RunTest` to benchmark your application. For example, create an adder_benchmark.go file with the following contents.

```go
package main

import (
    "context"
    "testing"

    "github.com/go-kod/kod"
)

func BenchmarkAdd(b *testing.B) {
    kod.RunTest(b, func(ctx context.Context, adder Adder) {
        b.ResetTimer()
        for i := 0; i < b.N; i++ {
            _, err := adder.Add(ctx, 1, 2)
            if err != nil {
                b.Fatal(err)
            }
        }
    })
}
```

#### Fake

You can replace a component implementation with a fake implementation in a test using `kod.Fake`. Here's an example where we replace the real implementation of a Clock component with a fake implementation that always returns a fixed time.

```go
// fakeClock is a fake implementation of the Clock component.
type fakeClock struct {
    now int64
}

// Now implements the Clock component interface. It returns the current time, in
// microseconds, since the unix epoch.
func (f *fakeClock) Now(context.Context) (int64, error) {
    return f.now, nil
}

func TestClock(t *testing.T) {
    t.Run("fake", func(t *testing.T) {
        // Register a fake Clock implementation with the runner.
        fake := kod.Fake[Clock](&fakeClock{100})

        // When a fake is registered for a component, all instances of that
        // component dispatch to the fake.
        kod.RunTest(t, func(ctx context.Context, clock Clock) {
            now, err := clock.UnixMicro(ctx)
            if err != nil {
                t.Fatal(err)
            }
            if now != 100 {
                t.Fatalf("bad time: got %d, want %d", now, 100)
            }

            fake.now = 200
            now, err = clock.UnixMicro(ctx)
            if err != nil {
                t.Fatal(err)
            }
            if now != 200 {
                t.Fatalf("bad time: got %d, want %d", now, 200)
            }
        }, kod.WithFakes(fake))
    })
}
```

#### Config

You can also provide the contents of a config file to a runner by setting the `Runner.Config` field:

```go
func TestArithmetic(t *testing.T) {
    kod.RunTest(t, func(ctx context.Context, adder Adder) {
        // ...
    }, kod.WithConfigFile("testdata/config.toml"))
}
```

### Logging

Kod provides a logging API, `kod.L`. Kod also integrates the logs into the environment where your application is deployed.

Use the Logger method of a component implementation to get a logger scoped to the component. For example:

```go
type Adder interface {
    Add(context.Context, int, int) (int, error)
}

type adder struct {
    kod.Implements[Adder]
}

func (a *adder) Add(ctx context.Context, x, y int) (int, error) {
    // adder embeds kod.Implements[Adder] which provides the L method.
    logger := a.L(ctx)
    logger.DebugContext(ctx, "A debug log.")
    logger.InfoContext(ctx, "An info log.")
    logger.ErrorContext(ctx, "An error log.", fmt.Errorf("an error"))
    return x + y, nil
}
```

### OpenTelemetry

Kod relies on OpenTelemetry to collect trace and metrics from your application.

Supported Environment Variables:

- `OTEL_SDK_DISABLED`: If set to true, disables the OpenTelemetry SDK. Default is false.
- `OTEL_LOGS_EXPORTER`: The logs exporter to use. Supported values are "console" and "otlp", Default is "otlp".
- `OTEL_EXPORTER_OTLP_PROTOCOL`: The protocol to use for the OTLP exporter. Supported values are "grpc" and "http/protobuf", Default is "http/protobuf".
- `OTEL_EXPORTER_OTLP_INSECURE`: If set to true, disables the security features of the OTLP exporter. Default is false.

More information can be found at [OpenTelemetry Website](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/).

### Acknowledge

This project was heavily inspired by [ServiceWeaver](https://github.com/ServiceWeaver/weaver).

## Star History

<a>
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=go-kod/kod&type=Timeline&theme=dark" />
    <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=go-kod/kod&type=Timeline" />
    <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=go-kod/kod&type=Timeline" />
  </picture>
</a>


A type safe, reflective framework for libraries, tests, http endpoints, and service startup

# nject - dependency injection 

[![Stability: Active](https://masterminds.github.io/stability/active.svg)](https://masterminds.github.io/stability/active.html)
[![GoDoc](https://godoc.org/github.com/muir/nject?status.png)](https://pkg.go.dev/github.com/muir/nject/v2)
![unit tests](https://github.com/muir/nject/actions/workflows/go.yml/badge.svg)
[![report card](https://goreportcard.com/badge/github.com/muir/nject)](https://goreportcard.com/report/github.com/muir/nject)
[![codecov](https://codecov.io/gh/muir/nject/branch/main/graph/badge.svg)](https://codecov.io/gh/muir/nject)

Install:

	go get github.com/muir/nject/v2

---

This package provides type-safe dependency injection without requiring
users to do type assertions.

Dependencies are injected via a call chain: list functions to be called
that take and return various parameters.  The functions will be called
in order using the return values from earlier functions as parameters
for later functions.  Only the functions that are needed to be called in
order to be able to call the last function in the chain are invoked.  Then
the last function in the chain is called.

Parameters are identified by their types.  To have two different `int`
parameters, define custom types.

Type safety is checked before any functions are called.

Functions whose outputs are not used are not called.  Functions may
"wrap" the rest of the list so that they can choose to invoke the
remaining list zero or more times.

Chains may be pre-compiled into closures so that they have very little
runtime penealty.

### example

	func example() {
		// Sequences can be reused.
		providerChain := Sequence("example sequence",
			// Constants can be injected.
			"a literal string value",
			// This function will be run if something downstream needs an int
			func(s string) int {
				return len(s)
			})
		Run("example",
			providerChain,
			// The last function in the list is always run.  This one needs
			// and int and a string.  The string can come from the constant
			// and the int from the function in the provider chain.
			func(i int, s string) {
				fmt.Println(i, len(s))
			})
	}

### Main APIs

Nject provides two main APIs: Bind() and Run().

Bind() is used when performance matters: given a chain of providers,
it will write two functions: one to initialize the chain and another to
invoke it.  As much as possible, all dependency injection work is done
at the time of binding and initialization so that the invoke function
operates with very little overhead.  The chain is initialized when the
initialize function is called.  The chain is run when the invoke function
is called.  Bind() does not run the chain.

Run() is used when ad-hoc injection is desired and performance is not
critical.  Run is appropriate when starting servers and running tests.
It is not recommended for HTTP endpoint handlers.  Run exectes the
chain immediately.

### Identified by type

Rather than naming values, inputs and outputs are identified by their types.  
Since Go makes it easy to create new types, this turns out to be quite easy to use.

### Types of providers

Multiple types of providers are supported.

#### Literal values

You can provide a constant if you have one.

#### Injectors

Regular functions can provide values.  Injectors will be called at
initialization time when they're marked as cacheable or at invocation
time if they're not.

Injectors can be memoized.

Injectors can return a special error type that stops the chain.

Injectors can use data produced by earlier injectors simply by having
a function parameter that matches the type of a return value of an
earlier injector.

Injector chains can be collapsed to become a single injector -- this
allows the chain to branch out in a tree structure so that it can 
generate multiple copies of the same type.

Injectors can be automatically reordered so that outputs are generated
before they're required as inputs.

#### Wrappers (aka Middleware)

Wrappers are special functions that are responsible for invoking
the part of the injection chain that comes after themselves.  They
do this by calling an `inner()` function that the nject framework
defines for them.

Any arguments to the inner() function are injected as values available
further down the chain.  Any return values from inner() must be returned
by the final function in the chain or from another wrapper further down
the chain.

### Composition

Collections of injectors may be composed by including them in
other collections.

## Debugging injector chains

If you chain successfully binds but does not do what you expect, add
something into your chain that receives the `nject.Debugging` type:

	func(d *nject.Debugging) {
		fmt.Println("Injectors included\n", d.Included)
	}

If you chain does not bind, then `Debugging` won't help.
Injection chain errors attempt to be self-explanatory, but sometimes that's not enough.

If you're building your injection sequence dynamically, it may be useful to print
the injection chain.  It has a `String()` method.

If you think that the issue is with nject, then open an issue with the reproduce information
that is available as part of the debugging (`Debugging.Reproduce`) or available by calling
`nject.DetailedError(err)` on the error returned from `Bind()` or `Run()`.

# Uses

Nject has been successfully used for:

- Test frameworks so that test authors specify the test dependencies with the types
  injected into a function that runs a test.  Using wrappers or `t.Clanup()` in the
  injection chain allows test writers to skip all or most test cleanup.
- Endpoint handlers.  Nject makes middleware easier to write.
- Server startup.

# Related packages

The following use nject to provide nicer APIs:

- [nape](https://github.com/muir/nape): dependency injection wrappers for binding http endpoint handlers using gorilla/mux
- [nchi](https://github.com/muir/nchi): http router on top of [httprouter](https://pkg.go.dev/github.com/julienschmidt/httprouter) with a go-chi-like API
- [nfigure](https://github.com/muir/nfigure): configuration and flag processing
- [npoint](https://github.com/muir/npoint): dependency injection wrappers for binding http endpoint handlers
- [nserve](https://github.com/muir/nserve): injection chains for for starting and stopping servers
- [ntest](https://github.com/memsql/ntest): support functions and hints for using nject to write tests
- [nvalid](https://github.com/muir/nvalid): enforce that http endpoints conform to Swagger definitions
- [nvelope](https://github.com/muir/nvelope): injection chains for building endpoints

### Development status

The core of nject is stable and reliable.  New features have tests, but may not have
enough production use to be reliable.

This repo represents continued development of Blue Owl's 
[nject](https://github.com/BlueOwlOpenSource/nject) base.

Nject will follow strict semver behavior except (1) things noted as experimental;
and (2) releases that are less than 10 days old may have corrections applied that
are not strictly backwards compatible with the recent release (for example, 1.0.0
accidentally exported a type that should have remained private).

Prior to release 0.2.0, nject was bundled with other packages.  Those
other packages are now in their own repos: 
[npoint](https://github.com/muir/npoint),
[nserve](https://github.com/muir/nserve), and
[nvelope](https://github.com/muir/nvelope).  Additionally, npoint
was split apart so that the gorilla dependency is separate and is in
[nape](https://github.com/muir/nape).

Please create issues for any suggested features, improvements, or problems you run into.



nject

Dependency injection using Generics and reflection

[![Go Version][gover-img]][gover] [![GoDoc][doc-img]][doc] [![Build Status][ci-img]][ci] [![Coverage Status][cov-img]][cov] [![GoReport][rpt-img]][rpt]

# Dependency injection for Go 1.18+ using Generics and reflection

## Functionalities

- Automatically wiring/injecting objects on creation.
- Easy to use (see Usage section).
- `Shared mode` by default that creates only one instance for a type (this option is configurable).
- Ability to overwrite objects of specific types on building which is convenient for unit testing.
- No code generation.

## Installation

```shell
go get github.com/tiendc/autowire
```

## Usage

### General usage

```go
    // Suppose you have ServiceA and a creator function
    type ServiceA interface {}
    func NewServiceA(srvB ServiceB, repoX RepoX) ServiceA {
        return <ServiceA-instance>
    }

    // and ServiceB
    type ServiceB interface {}
    func NewServiceB(ctx context.Context, repoX RepoX, repoY RepoY) (ServiceB, error) {
        return <ServiceB-instance>, nil
    }

    // and RepoX
    type RepoX interface {}
    func NewRepoX(s3Client S3Client) (RepoX, error) {
        return <RepoX-instance>, nil
    }

    // and RepoY
    type RepoY interface {}
    func NewRepoY(redisClient RedisClient) RepoY {
        return <RepoY-instance>
    }

    // and a struct provider
    type ProviderStruct struct {
        RedisClient RedisClient
        S3Client    S3Client
    }

    var (
        // init the struct value
        providerStruct = &ProviderStruct{...}

        // create a container with passing providers
        container = MustNewContainer([]any{
            // Service providers
            NewServiceA,
            NewServiceB,
            // Repo providers
            NewRepoX,
            NewRepoY,
            // Struct provider (must be a pointer)
            providerStruct,
        })
    )

    func main() {
        // Update some values of the struct provider
        providerStruct.RedisClient = newRedisClient()
        providerStruct.S3Client = newS3Client()

        // Create ServiceA
        serviceA, err := autowire.BuildWithCtx[ServiceA](ctx, container)
        // Create RepoX
        repoX, err := autowire.Build[RepoX](container)
    }
```

### Non-shared mode

```go
    // Set sharedMode when create a container
    container = MustNewContainer([]any{
        // your providers
    }, SetSharedMode(false))

    // Activate non-shared mode inline for a specific build only
    serviceA, err := Build[ServiceA](container, NonSharedMode())
```

### Overwrite values of specific types

This is convenient in unit testing to overwrite specific types only.

```go
    // In unit testing, you may want to overwrite some `repos` and `clients` with fake instances.
    // NOTE: you may need to use `non-shared mode` to make sure cached objects are not used.
    serviceA, err := Build[ServiceA](container, NonSharedMode(),
            ProviderOverwrite[RepoX](fakeRepoX),
            ProviderOverwrite[RepoY](fakeRepoY))
    serviceA, err := Build[ServiceA](container, NonSharedMode(),
            ProviderOverwrite[RedisClient](fakeRedisClient),
            ProviderOverwrite[S3Client](fakeS3Client))
```

### Reclaim memory after use

Typically, dependency injection is only used at the initialization phase of a program.
However, it can take some space in memory which will become wasted after the phase.
Use the below trick to reclaim the memory taken by the autowire variables.

```go
    var (
        // create a global container
        container = MustNewContainer(...)
    )

    func autowireCleanUp() {
        // Assign nil to allow the garbage collector to reclaim the taken memory
        container = nil
    }

    func main() {
        // Initialization phase
        // Create services and use them
        serviceA, _ := autowire.Build[ServiceA](container)
        serviceB, _ := autowire.Build[ServiceB](container)

        // Clean up the usage, make sure you won't use the vars any more
        autowireCleanUp()
    }
```

## Contributing

- You are welcome to make pull requests for new functions and bug fixes.

## License

- [MIT License](LICENSE)

[doc-img]: https://pkg.go.dev/badge/github.com/tiendc/autowire
[doc]: https://pkg.go.dev/github.com/tiendc/autowire
[gover-img]: https://img.shields.io/badge/Go-%3E%3D%201.18-blue
[gover]: https://img.shields.io/badge/Go-%3E%3D%201.18-blue
[ci-img]: https://github.com/tiendc/autowire/actions/workflows/go.yml/badge.svg
[ci]: https://github.com/tiendc/autowire/actions/workflows/go.yml
[cov-img]: https://codecov.io/gh/tiendc/autowire/branch/main/graph/badge.svg
[cov]: https://codecov.io/gh/tiendc/autowire
[rpt-img]: https://goreportcard.com/badge/github.com/tiendc/autowire
[rpt]: https://goreportcard.com/report/github.com/tiendc/autowire


autowire

A dependency injection toolkit for Go, based on Guice

# Dingo

[![Go Report Card](https://goreportcard.com/badge/flamingo.me/dingo)](https://goreportcard.com/report/flamingo.me/dingo) [![GoDoc](https://godoc.org/flamingo.me/dingo?status.svg)](https://godoc.org/flamingo.me/dingo) [![Tests](https://github.com/i-love-flamingo/dingo/workflows/Tests/badge.svg?branch=master)](https://github.com/i-love-flamingo/dingo/actions?query=branch%3Amaster+workflow%3ATests)

Dependency injection for go

## Hello Dingo

Dingo works very similar to [Guice](https://github.com/google/guice/wiki/GettingStarted)

Basically one binds implementations/factories to interfaces, which are then resolved by Dingo.

Given that Dingo's idea is based on Guice we use similar examples in this documentation:

The following example shows a BillingService with two injected dependencies. Please note
that Go's nature does not allow constructors, and does not allow decorations/annotations
beside struct-tags, thus, we only use struct tags (and later arguments for providers).

Also, Go does not have a way to reference types (like Java's `Something.class`) we use either pointers
or `nil` and cast it to a pointer to the interface we want to specify: `(*Something)(nil)`.
Dingo then knows how to dereference it properly and derive the correct type `Something`.
This is not necessary for structs, where we can just use the null value via `Something{}`.

See the example folder for a complete example.

```go
package example

type BillingService struct {
	processor CreditCardProcessor
	transactionLog TransactionLog
}

func (billingservice *BillingService) Inject(processor CreditCardProcessor, transactionLog TransactionLog) {
	billingservice.processor = processor
	billingservice.transactionLog = transactionLog
}

func (billingservice *BillingService) ChargeOrder(order PizzaOrder, creditCard CreditCard) Receipt {
	// ...
}
```

We want the BillingService to get certain dependencies, and configure this in a `BillingModule`
which implements `dingo.Module`:

```go
package example

type BillingModule struct {}

func (module *BillingModule) Configure(injector *dingo.Injector) {
	// This tells Dingo that whenever it sees a dependency on a TransactionLog, 
	// it should satisfy the dependency using a DatabaseTransactionLog. 
	injector.Bind(new(TransactionLog)).To(DatabaseTransactionLog{})

	// Similarly, this binding tells Dingo that when CreditCardProcessor is used in
	// a dependency, that should be satisfied with a PaypalCreditCardProcessor. 
	injector.Bind(new(CreditCardProcessor)).To(PaypalCreditCardProcessor{})
}
```

## Requesting injection

Every instance that is created through the container can use injection. 

Dingo supports two ways of requesting dependencies that should be injected:

* usage of struct tags to allow structs to request injection into fields. This should be used for public fields.
* implement a public Inject(...) method to request injections of private fields. Dingo calls this method automatically and passes the requested injections.

For every requested injection (unless an exception applies) Dingo does the following:

- Is there a binding? If so: delegate to the binding
    - Is the binding in a certain scope (Singleton)? If so, delegate to scope (might result in a new loop)
    - Binding is bound to an instance: inject instance
    - Binding is bound to a provider: call provider
    - Binding is bound to a type: request injection of this type (might return in a new loop to resolve the binding)
- No binding? Try to create (only possible for concrete types, not interfaces or functions)


*Example:*
Here is another example using the Inject method for private fields
```go
package example

type MyBillingService struct {
	processor CreditCardProcessor
	accountId string
}

func (m *MyBillingService) Inject(
	processor CreditCardProcessor,
	config *struct {
		AccountId  string `inject:"config:myModule.myBillingService.accountId"`
	},
) {
	m.processor = CreditCardProcessor
	m.accountId = config.AccountId
}
```

### Usage of Providers

Dingo allows to request the injection of provider instead of instances.
A "Provider" for dingo is a function that return a new Instance of a certain type.

```go
package example

type pizzaProvider func() Pizza

func (s *Service) Inject(provider pizzaProvider) {
	s.provider = provider
}
```

If there is no concrete binding to the type `func() Pizza`, then instead of constructing one `Pizza` instance
Dingo will create a new function which, on every call, will return a new instance of `Pizza`.

The type must be of `func() T`, a function without any arguments which returns a type, which again has a binding.

This allows to lazily create new objects whenever needed, instead of requesting the Dingo injector itself.


You can use Providers and call them to always get a new instance.
Dingo will provide you with an automatic implementation of a Provider if you did not bind a specific one.

*Use a Provider instead of requesting the Type directly when*:

* for lazy binding 
* if you need new instances on demand
* In general, it is best practice using a Provider for everything that has a state that might be changed. This way you will avoid undesired side effects. That is especially important for dependencies in objects that are shared between requests - for example a controller!

*Example 1:*
This is the only code required to request a Provider as a dependency:
```go
MyStructProvider func() *MyStruct
MyStruct         struct {}

MyService struct {
	MyStructProvider MyStructProvider `inject:""`
}

```

*Example 2:*
```go
package example

func createSomething(thing SomethingElse) Something{
	return &MySomething{somethingElse: thing}
}

injector.Bind(new(Something)).ToProvider(createSomething)

type somethingProvider func() Something

type service struct {
	provider somethingProvider
}
```

will essentially call `createSomething(new(SomethingElse))` everytime `SomethingProvider()` is called,
passing the resulting instance through the injection to finalize uninjected fields. 


### Optional injection

An injection struct tag can be marked as optional by adding the suffix `,optional` to it.
This means that for interfaces, slices, pointers etc where dingo can not resolve a concrete type, the `nil`-type is injected.

You can check via `if my.Prop == nil` if this is nil.

## Bindings

Dingo uses bindings to express dependencies resolutions, and will panic if there is more than one
binding for a type with the same name (or unnamed), unless you use multibindings.

### Bind

Bind creates a new binding, and tells Dingo how to resolve the type when it encounters a request for this type.
Bindings can chain, but need to implement the correct interfaces.

```go
injector.Bind(new(Something))
```

### AnnotatedWith

By default a binding is unnamed, and thus requested with the `inject:""` tag.

However, you can name bindings to have more concrete kinds of it. Using `AnnotatedWith` you can specify the name:

```go
injector.Bind((*Something)(nil)).AnnotatedWith("myAnnotation")
```

It is requested via the `inject:"myAnnotation"` tag. For example:

```go
struct {
	PaypalPaymentProcessor PaymentProcessor `inject:"Paypal"`
}
```

### To

To defines which type should be created when this type is requested.
This can be an Interface which implements to one it is bound to, or a concrete type.
The type is then created via `reflect.New`.

```go
injector.Bind(new(Something)).To(MyType{})
```

### ToProvider

If you want a factory to create your types then you rather use `ToProvider` instead of `To`.

`ToProvider` is a function which returns an instance (which again will go through Dingo to fill dependencies).

Also, the provider can request arguments from Dingo which are necessary to construct the bounded type.
If you need named arguments (e.g. a string instance annotated with a configuration value) you need to request
an instance of an object with these annotations, because Go does not allow to pass any meta-information on function
arguments.

```go
func MyTypeProvider(se SomethingElse) *MyType {
	return &MyType{
		Special: se.DoSomething(),
	}
}

injector.Bind(new(Something)).ToProvider(MyTypeProvider)
```

This example will make Dingo call `MyTypeProvider` and pass in an instance of `SomethingElse` as it's first argument,
then take the result of `*MyType` as the value for `Something`.

`ToProvider` takes precedence over `To`.

### ToInstance

For situations where you have one, and only one, concrete instance you can use `ToInstance` to bind
something to the concrete instance. This is not the same as a Singleton!
(Even though the resulting behaviour is very similar.)

```go
var myInstance = new(MyType)
myInstance.Connect(somewhere)
injector.Bind(new(Something)).ToInstance(myInstance)
```

You can also bind an instance it to a struct obviously, not only to interfaces.

`ToInstance` takes precedence over both `To` and `ToProvider`.

### In (Singleton scopes)

If really necessary it is possible to use singletons
``` 
.AsEagerSingleton() binds as a singleton, and loads it when the application is initialized
.In(dingo.Singleton) makes it a global singleton
.In(dingo.ChildSingleton) makes it a singleton limited to the current injector
```

`In` allows us to bind in a scope, making the created instances scoped in a certain way.

Currently, Dingo only allows to bind to `dingo.Singleton` and `dingo.ChildSingleton`.

```go
injector.Bind(new(Something)).In(dingo.Singleton).To(MyType{})
```

#### dingo.Singleton

The `dingo.Singleton` scope makes sure a dependency is only resolved once, and the result is
reused. Because the Singleton needs synchronisation for types over multiple concurrent
goroutines and make sure that a Singleton is only created once, the initial creation
can be costly and also the injection of a Singleton is always taking more resources than creation
of an immutable new object.

The synchronisation is done on multiple levels, a first test tries to find the singleton,
if that is not possible a lock-mechanism via a scoped Mutex takes care of delegating
the concrete creation to one goroutine via a scope+type specific Mutex which then generates
the Singleton and makes it available to other currently waiting injection requests, as
well as future injection requests.

By default, it is advised to not use Singletons whenever possible, and rather use
immutable objects you inject whenever you need them.

#### dingo.ChildSingleton

The ChildSingleton is just another Singleton (actually of the same type), but dingo will create a new one
for every derived child injector.

This allows frameworks like Flamingo to distinguish at a root level between singleton scopes, e.g. for
multi-page setups where we need a wide scope for routers.

Since ChildSingleton is very similar to Singleton you should only use it with care.

#### AsEagerSingleton

Singleton creation is always costly due to synchronisation overhead, therefore
Dingo bindings allow to mark a binding `AsEagerSingleton`.

This makes sure the Singleton is created as soon as possible, before the rest of the Application
runs. `AsEagerSingleton` implies `In(dingo.Singleton)`.

```go
injector.Bind(new(Something)).To(MyType{}).AsEagerSingleton()
```

It is also possible to bind a concrete type without `To`:

```go
injector.Bind(MyType{}).AsEagerSingleton()
```

Binding this type as an eager singleton inject the singleton instance whenever `MyType` is requested. `MyType` is a concrete type (struct) here, so we can use this mechanism to create an instance explicitly before the application is run.

### Override

In rare cases you might have to override an existing binding, which can be done with `Override`:

```go
injector.Override(new(Something), "").To(MyBetterType{})
```

`Override` also returns a binding such as `Bind`, but removes the original binding.

The second argument sets the annotation if you want to override a named binding.

### MultiBindings

MultiBindings provide a way of binding multiple implementations of a type to a type,
making the injection a list.

Essentially this means that multiple modules are able to register for a type, and a user of this
type can request an injection of a slice `[]T` to get a list of all registered bindings.

```go
injector.BindMulti(new(Something)).To(MyType1{})
injector.BindMulti(new(Something)).To(MyType2{})

struct {
	List []Something `inject:""`  // List is a slice of []Something{MyType1{}, MyType2{}}
}
```

MultiBindings are used to allow multiple modules to register for a certain type, such as a list of
encoders, subscribers, etc.

Please note that MultiBindings are not always a clear pattern, as it might hide certain complexity.

Usually it is easier to request some kind of registry in your module, and then register explicitly.


### Bind maps

Similar to Multibindings, but with a key instead of a list
```go
MyService struct {
	Ifaces map[string]Iface `inject:""`
}

injector.BindMap(new(Iface), "impl1").To(IfaceImpl{})
injector.BindMap(new(Iface), "impl2").To(IfaceImpl2{})
```

### Binding basic types

Dingo allows binding values to `int`, `string` etc., such as with any other type.

This can be used to inject configuration values.

Flamingo makes an annotated binding of every configuration value in the form of:

```go
var Configuration map[string]interface{}

for k, v := range Configuration {
	injector.Bind(v).AnnotatedWith("config:" + k).ToInstance(v)
}
```

In this case Dingo learns the actual type of `v` (such as string, bool, int) and provides the annotated injection.

Later this can be used via

```go
struct {
	ConfigParam string `inject:"config:myconfigParam"`
}
```



## Dingo Interception

Dingo allows modules to bind interceptors for interfaces.

Essentially this means that whenever the injection of a certain type is happening,
the interceptor is injected instead with the actual injection injected into the interceptor's
first field. This mechanism can only work for interface interception.

Multiple interceptors stack upon each other.

Interception should be used with care!

```go
func (m *Module) Configure(injector *dingo.Injector) {
	injector.BindInterceptor(new(template.Engine), TplInterceptor{})
	injector.BindInterceptor(new(template.Function), FunctionInterceptor{})
}

type (
	TplInterceptor struct {
		template.Engine
	}

	FunctionInterceptor struct {
		template.Function
	}
)

func (t *TplInterceptor) Render(context web.Context, name string, data interface{}) io.Reader {
	slog.Info("Before Rendering", name)
	start := time.Now()
	r := t.Engine.Render(context, name, data)
	slog.Info("After Rendering", time.Since(start))
	return r
}

func (f *FunctionInterceptor) Name() string {
	funcname := f.Function.Name()
	slog.Info("Function", funcname, "used")
	return funcname
}
```

## Initializing Dingo
At the topmost level the injector is created and used in the following way:

```go
package main

import "flamingo.me/dingo"

func main() {
	injector, err := dingo.NewInjector()
	if err != nil {
		panic(err)
	}

	// The injector can be initialized by modules:
	injector.InitModules(new(BillingModule))

	// Now that we've got the injector, we can build objects.
	// We get a new instance, and cast it accordingly:
	instance, err := injector.GetInstance(new(BillingService))
	if err != nil {
		panic(err)
	}
    billingService := instance.(BillingService) 
	//...
}
```

## Dingo vs. Wire

Recently https://github.com/google/go-cloud/tree/master/wire popped out in the go ecosystem, which seems to be a great choice, also because it supports compile time dependency injection.
However, when Dingo was first introduced wire was not a thing, and wire still lacks features dingo provides. 

https://gocover.io/github.com/i-love-flamingo/dingo

## ModuleFunc

Dingo has a wrapper for `func(*Injector)` called `ModuleFunc`. It is possible to wrap a function with the `ModuleFunc` to become a `Module`.
This is similar to the `http` Packages `HandlerFunc` mechanism and allows to save code and easier set up small projects.

## Troubleshooting
1. To trace possible circular injections Dingo has function `EnableCircularTracing()`, which also switches slog to DEBUG level. This makes execution very heavy in terms of memory, so should be used only for debug purposes.
2. To trace possible injection issues, like when Dingo tries to inject dependency into unexported field and fails, and user does not know where this happens, Dingo has `EnableInjectionTracing()`, which is also sets slog level to DEBUG. 


dingo

A dependency injection framework based on Generics


# do - Dependency Injection

[![tag](https://img.shields.io/github/tag/samber/do.svg)](https://github.com/samber/do/releases)
![Go Version](https://img.shields.io/badge/Go-%3E%3D%201.18-%23007d9c)
[![GoDoc](https://godoc.org/github.com/samber/do?status.svg)](https://pkg.go.dev/github.com/samber/do)
![Build Status](https://github.com/samber/do/actions/workflows/test.yml/badge.svg)
[![Go report](https://goreportcard.com/badge/github.com/samber/do)](https://goreportcard.com/report/github.com/samber/do)
[![Coverage](https://img.shields.io/codecov/c/github/samber/do)](https://codecov.io/gh/samber/do)
[![License](https://img.shields.io/github/license/samber/do)](./LICENSE)

**⚙️ A dependency injection toolkit based on Go 1.18+ Generics.**

This library implements the Dependency Injection design pattern. It may replace the fantastic `uber/dig` package. `samber/do` uses Go 1.18+ generics and therefore offers a type‑safe API.

![image](https://github.com/user-attachments/assets/81b91fa7-cdb4-4094-94ba-a0179abc6bf7)

**See also:**

- [samber/ro](https://github.com/samber/ro): Reactive Programming for Go: declarative and composable API for event-driven applications
- [samber/lo](https://github.com/samber/lo): A Lodash-style Go library based on Go 1.18+ Generics
- [samber/mo](https://github.com/samber/mo): Monads based on Go 1.18+ Generics (Option, Result, Either...)
- [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang): AI Agent Skills for Golang

----

<div align="center">
  <sup><b>💖 Sponsored by:</b></sup>
  <br>
  <a href="https://www.dbos.dev/?utm_campaign=gh-smbr">
    <div>
	  <img width="200" alt="dbos" src="https://github.com/user-attachments/assets/d583cb62-7735-4d3c-beb7-e6ef1a5faf49" />
    </div>
    <div>
      DBOS - Durable workflow orchestration library for Go
    </div>
  </a>
</div>

----

**Why this name?**

I love the **short name** for such a utility library. This name is the sum of `DI` and `Go` and no Go package uses this name.

## 💡 Features

- **📒 Service registration**
  - Register by type
  - Register by name
  - Register multiple services from a package at once
- **🪃 Service invocation**
  - Eager loading
  - Lazy loading
  - Transient loading
  - Tag-based invocation
  - Circular dependency detection
- **🧙‍♂️ Service aliasing**
  - Implicit (provide struct, invoke interface)
  - Explicit (provide struct, bind interface, invoke interface)
- **🔁 Service lifecycle**
  - Health check
  - Graceful unload (shutdown)
  - Dependency-aware parallel shutdown
  - Lifecycle hooks
- **📦 Scope (a.k.a module) tree**
  - Visibility control
  - Dependency grouping
- **📤 Container**
  - Dependency graph resolution and visualization
  - Default container
  - Container cloning
  - Service override
- **🧪 Debugging & introspection**
  - Explain APIs: scope tree and service dependencies
  - Web UI & HTTP middleware (std, Gin, Fiber, Echo, Chi)
- **🌈 Lightweight, no dependencies**
- **🔅 No code generation**
- **😷 Type‑safe API**

## 🚀 Install

```sh
# v2 (latest)
go get github.com/samber/do/v2@latest

# v1
go get github.com/samber/do@v1.6.0

# AI Agent Skill
npx skills add https://github.com/samber/cc-skills-golang --skill golang-samber-do
```

This library is v2 and follows SemVer strictly.

No breaking changes will be made to exported APIs before v3.0.0.

This library has no dependencies except the Go std lib.

### 🔥 Migration from v1 to v2

[Documentation here](https://do.samber.dev/docs/upgrading/from-v1-x-to-v2)

## 🤠 Documentation

- [GoDoc: https://godoc.org/github.com/samber/do/v2](https://godoc.org/github.com/samber/do/v2)
- [Documentation](https://do.samber.dev/docs/getting-started)
- [Examples](https://github.com/samber/do/tree/master/examples)
- [Project templates](https://do.samber.dev/examples)

## 🎬 Project boilerplate

- [do-template-api](https://github.com/samber/do-template-api)
- [do-template-worker](https://github.com/samber/do-template-worker)
- [do-template-cli](https://github.com/samber/do-template-cli)

## 🤝 Contributing

- Ping me on Twitter [@samuelberthe](https://twitter.com/samuelberthe) (DMs, mentions, whatever :))
- Fork the [project](https://github.com/samber/do)
- Fix [open issues](https://github.com/samber/do/issues) or request new features

Don't hesitate ;)

```bash
# Install some dev dependencies
make tools

# Run tests
make test
# or
make watch-test
```

## 👤 Contributors

![Contributors](https://contrib.rocks/image?repo=samber/do)

## 💫 Show your support

Give a ⭐️ if this project helped you!

[![GitHub Sponsors](https://img.shields.io/github/sponsors/samber?style=for-the-badge)](https://github.com/sponsors/samber)

## 📝 License

Copyright © 2022 [Samuel Berthe](https://github.com/samber).

This project is [MIT](./LICENSE) licensed.


Spring-inspired Dependency Injection Container

# goioc/di: Dependency Injection
[![goioc](https://habrastorage.org/webt/ym/pu/dc/ympudccm7j7a3qex_jjroxgsiwg.png)](https://github.com/goioc)

[![Go](https://github.com/goioc/di/workflows/Go/badge.svg)](https://github.com/goioc/di/actions)
[![go.dev reference](https://img.shields.io/badge/go.dev-reference-007d9c?logo=go&logoColor=white&style=flat-square)](https://pkg.go.dev/github.com/goioc/di/?tab=doc)
[![CodeFactor](https://www.codefactor.io/repository/github/goioc/di/badge)](https://www.codefactor.io/repository/github/goioc/di)
[![Go Report Card](https://goreportcard.com/badge/github.com/goioc/di)](https://goreportcard.com/report/github.com/goioc/di)
[![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=goioc_di&metric=alert_status)](https://sonarcloud.io/dashboard?id=goioc_di)
[![codecov](https://codecov.io/gh/goioc/di/branch/master/graph/badge.svg)](https://codecov.io/gh/goioc/di)
[![DeepSource](https://static.deepsource.io/deepsource-badge-light-mini.svg)](https://deepsource.io/gh/goioc/di/?ref=repository-badge)
[![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/sindresorhus/awesome)

[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/G2G5JUKU7)

## Why DI in Go? Why IoC at all?
I've been using Dependency Injection in Java for nearly 10 years via [Spring Framework](https://spring.io/). I'm not saying that one can't live without it, but it's proven to be very useful for large enterprise-level applications. You may argue that Go follows a completely different ideology, values different principles and paradigms than Java, and DI is not needed in this better world. And I can even partly agree with that. And yet I decided to create this light-weight Spring-like library for Go. You are free to not use it, after all 🙂

## Is it the only DI library for Go?
No, of course not. There's a bunch of libraries around which serve a similar purpose (I even took inspiration from some of them). The problem is that I was missing something in all of these libraries... Therefore I decided to create Yet Another IoC Container that would rule them all. You are more than welcome to use any other library, for example [this nice project](https://github.com/sarulabs/di). And still, I'd recommend stopping by here 😉

## So, how does it work? 
It's better to show than to describe. Take a look at this toy-example (error-handling is omitted to minimize code snippets):

**services/weather_service.go**
```go
package services

import (
	"io"
	"net/http"
)

type WeatherService struct {
}

func (ws *WeatherService) Weather(city string) (*string, error) {
	response, err := http.Get("https://wttr.in/" + city)
	if err != nil {
		return nil, err
	}
	all, err := io.ReadAll(response.Body)
	if err != nil {
		return nil, err
	}
	weather := string(all)
	return &weather, nil
}
```

**controllers/weather_controller.go**
```go
package controllers

import (
	"di-demo/services"
	"github.com/goioc/di"
	"net/http"
)

type WeatherController struct {
	// note that injection works even with unexported fields
	weatherService *services.WeatherService `di.inject:"weatherService"`
}

func (wc *WeatherController) Weather(w http.ResponseWriter, r *http.Request) {
	weather, _ := wc.weatherService.Weather(r.URL.Query().Get("city"))
	_, _ = w.Write([]byte(*weather))
}
```

**init.go**
```go
package main

import (
	"di-demo/controllers"
	"di-demo/services"
	"github.com/goioc/di"
	"reflect"
)

func init() {
	_, _ = di.RegisterBean("weatherService", reflect.TypeOf((*services.WeatherService)(nil)))
	_, _ = di.RegisterBean("weatherController", reflect.TypeOf((*controllers.WeatherController)(nil)))
	_ = di.InitializeContainer()
}
```

**main.go**
```go
package main

import (
	"di-demo/controllers"
	"github.com/goioc/di"
	"net/http"
)

func main() {
	http.HandleFunc("/weather", func(w http.ResponseWriter, r *http.Request) {
		di.GetInstance("weatherController").(*controllers.WeatherController).Weather(w, r)
	})
	_ = http.ListenAndServe(":8080", nil)
}
```

If you run it, you should be able to observe a neat weather forecast at http://localhost:8080/weather?city=London (or for any other city).

Of course, for such a simple example it may look like an overkill. But for larger projects with many interconnected services with complicated business logic, it can really simplify your life!

## Looks nice... Give me some details!

The main component of the library is the [Inversion of Control Container](https://www.martinfowler.com/articles/injection.html) that contains and manages instances of your structures (called "beans").

### Types of beans

- **Singleton**. Exists only in one copy in the container. Every time you retrieve the instance from the container (or every time it's being injected to another bean) - it will be the same instance.
- **Prototype**. It can exist in multiple copies: a new copy is created upon retrieval from the container (or upon injection into another bean).
- **Request**. Similar to `Prototype`, however it has a few differences and features (since its lifecycle is bound to a web request):
   - Can't be injected to other beans.
   - Can't be manually retrieved from the Container.
   - `Request` beans are automatically injected to the `context.Context` of a corresponding `http.Request`. 
   - If a `Request` bean implements `io.Closer`, it will be "closed" upon corresponding request's cancellation.

### Beans registration

For the container to become aware of the beans, one must register them manually (unlike Java, unfortunately, we can't scan classpath to do it automatically, because Go runtime doesn't contain high-level information about types). How can one register beans in the container?

- **By type**. This is described in the example above. A structure is declared with a field tagged with `di.scope:"<scope>"`. This field can be even omitted - in this case, the default scope will be `Singleton`. Then the registration is done like this:
```go
di.RegisterBean("beanID", reflect.TypeOf((*YourAwesomeStructure)(nil)))
```

- **Using pre-created instance**. What if you already have an instance that you want to register as a bean? You can do it like this:
```go
di.RegisterBeanInstance("beanID", yourAwesomeInstance)
```
For this type of beans, the only supported scope is `Singleton`, because I don't dare to clone your instances to enable prototyping 😅

- **Via bean factory**. If you have a method that is producing instances for you, you can register it as a bean factory:
```go
di.RegisterBeanFactory("beanID", Singleton, func(context.Context) (interface{}, error) {
		return "My awesome string that is going to become a bean!", nil
	})
```
Feel free to use any scope with this method. By the way, you can even lookup other beans within the factory:
```go
di.RegisterBeanFactory("beanID", Prototype, func(context.Context) (interface{}, error) {
		return di.GetInstance("someOtherBeanID"), nil
	})
```
Note that factory-method accepts `context.Context`. It can be useful for request-scoped beans (the HTTP request context is set in this case). For all other beans it will be `context.Background()`.

### Beans initialization

There's a special interface `InitializingBean` that can be implemented to provide your bean with some initialization logic that will be executed after the container is initialized (for `Singleton` beans) or after the `Prototype`/`Request` instance is created. Again, you can also lookup other beans during initialization (since the container is ready by that time):

```go
type PostConstructBean1 struct {
	Value string
}

func (pcb *PostConstructBean1) PostConstruct() error {
	pcb.Value = "some content"
	return nil
}

type PostConstructBean2 struct {
	Scope              Scope `di.scope:"prototype"`
	PostConstructBean1 *PostConstructBean1
}

func (pcb *PostConstructBean2) PostConstruct() error {
	instance, err := di.GetInstanceSafe("postConstructBean1")
	if err != nil {
		return err
	}
	pcb.PostConstructBean1 = instance.(*PostConstructBean1)
	return nil
}
```

### Beans post-processors

The alternative way of initializing beans is using so-called "beans post-processors". Take a look at the example:

```go
type postprocessedBean struct {
	a string
	b string
}

_, _ := RegisterBean("postprocessedBean", reflect.TypeOf((*postprocessedBean)(nil)))

_ = RegisterBeanPostprocessor(reflect.TypeOf((*postprocessedBean)(nil)), func(instance interface{}) error {
    instance.(*postprocessedBean).a = "Hello, "
    return nil
})

_ = RegisterBeanPostprocessor(reflect.TypeOf((*postprocessedBean)(nil)), func(instance interface{}) error {
instance.(*postprocessedBean).b = "world!"
    return nil
})

_ = InitializeContainer()

instance := GetInstance("postprocessedBean")

postprocessedBean := instance.(*postprocessedBean)
println(postprocessedBean.a+postprocessedBean.b) // prints out "Hello, world!"
```

### Beans injection

As was mentioned above, one bean can be injected into another with the `PostConstruct` method. However, the more handy way of doing it is by using a special tag:

```go
type SingletonBean struct {
	SomeOtherBean *SomeOtherBean `di.inject:"someOtherBean"`
}
```

... or via interface ...

```go
type SingletonBean struct {
	SomeOtherBean SomeOtherBeansInterface `di.inject:"someOtherBean"`
}
```

Note that you can refer dependencies either by pointer, or by interface, but not by value. And just a reminder: you can't inject `Request` beans.

Sometimes we might want to have optional dependencies. By default, all declared dependencies are considered to be required: if some dependency is not found in the Container, you will get an error. However, you can specify an optional dependency like this:

```go
type SingletonBean struct {
	SomeOtherBean *string `di.inject:"someOtherBean" di.optional:"true"`
}
```

In this case, if `someOtherBean` is not found in the Container, you will get `nil` injected into this field.

In fact, you don't need a bean ID to preform an injection! Check this out:

```go
type SingletonBean struct {
	SomeOtherBean *string `di.inject:""`
}
```

In this case, DI will try to find a candidate for the injection automatically (among registered beans of type `*string`). Cool, ain't it? 🤠
It will panic though if no candidates are found (and if the dependency is not marked as optional), or if there is more than one candidate found. 

Finally, you can inject beans to slices and maps. It works similarly to the ID-less inections above, but injects all candidates that were found:

```go
type SingletonBean struct {
	someOtherBeans []*string `di.inject:""`
}
```

```go
type SingletonBean struct {
	someOtherBeans map[string]*string `di.inject:""`
}
```

### Circular dependencies

The problem with all IoC containers is that beans' interconnection may suffer from so-called circular dependencies. Consider this example:

```go
type CircularBean struct {
	Scope        Scope         `di.scope:"prototype"`
	CircularBean *CircularBean `di.inject:"circularBean"`
}
```

Trying to use such bean will result in the `circular dependency detected for bean: circularBean` error. There's no problem as such with referencing a bean from itself - if it's a `Singleton` bean. But doing it with `Prototype`/`Request` beans will lead to infinite creation of the instances. So, be careful with this: "with great power comes great responsibility" 🕸 

## What about middleware?

We have some 😎 Here's an example with [gorilla/mux](https://github.com/gorilla/mux) router (but feel free to use any other router). 
Basically, it's an extension of the very first example with the weather controller, but this time we add `Request` beans and access them via request's context. 
Also, this example demonstrates how DI can automatically close resources for you (DB connection in this case). The proper error handling is, again, omitted for simplicity.

**controllers/weather_controller.go**
```go
package controllers

import (
	"database/sql"
	"di-demo/services"
	"github.com/goioc/di"
	"net/http"
)

type WeatherController struct {
	// note that injection works even with unexported fields
	weatherService *services.WeatherService `di.inject:"weatherService"`
}

func (wc *WeatherController) Weather(w http.ResponseWriter, r *http.Request) {
	dbConnection := r.Context().Value(di.BeanKey("dbConnection")).(*sql.Conn)
	city := r.URL.Query().Get("city")
	_, _ = dbConnection.ExecContext(r.Context(), "insert into log values (?, ?, datetime('now'))", city, r.RemoteAddr)
	weather, _ := wc.weatherService.Weather(city)
	_, _ = w.Write([]byte(*weather))
}
```

**controllers/index_controller.go**
```go
package controllers

import (
	"database/sql"
	"fmt"
	"github.com/goioc/di"
	"net/http"
	"strings"
	"time"
)

type IndexController struct {
}

func (ic *IndexController) Log(w http.ResponseWriter, r *http.Request) {
	dbConnection := r.Context().Value(di.BeanKey("dbConnection")).(*sql.Conn)
	rows, _ := dbConnection.QueryContext(r.Context(), "select * from log")
	columns, _ := rows.Columns()
	_, _ = w.Write([]byte(strings.ToUpper(fmt.Sprintf("Requests log: %v\n\n", columns))))
	for rows.Next() {
		var city string
		var ip string
		var dateTime time.Time
		_ = rows.Scan(&city, &ip, &dateTime)
		_, _ = w.Write([]byte(fmt.Sprintln(city, "\t", ip, "\t", dateTime)))
	}
}
```

**init.go**
```go
package main

import (
	"context"
	"database/sql"
	"di-demo/controllers"
	"di-demo/services"
	"github.com/goioc/di"
	"os"
	"reflect"
)

func init() {
	_, _ = di.RegisterBean("weatherService", reflect.TypeOf((*services.WeatherService)(nil)))
	_, _ = di.RegisterBean("indexController", reflect.TypeOf((*controllers.IndexController)(nil)))
	_, _ = di.RegisterBean("weatherController", reflect.TypeOf((*controllers.WeatherController)(nil)))
	_, _ = di.RegisterBeanFactory("db", di.Singleton, func(context.Context) (interface{}, error) {
		_ = os.Remove("./di-demo.db")
		db, _ := sql.Open("sqlite3", "./di-demo.db")
		db.SetMaxOpenConns(1)
		_, _ = db.Exec("create table log ('city' varchar not null, 'ip' varchar not null, 'time' datetime not null)")
		return db, nil
	})
	_, _ = di.RegisterBeanFactory("dbConnection", di.Request, func(ctx context.Context) (interface{}, error) {
		db, _ := di.GetInstanceSafe("db")
		return db.(*sql.DB).Conn(ctx)
	})
	_ = di.InitializeContainer()
}
```

**main.go**
```go
package main

import (
	"di-demo/controllers"
	"github.com/goioc/di"
	"github.com/gorilla/mux"
	_ "github.com/mattn/go-sqlite3"
	"net/http"
)

func main() {
	router := mux.NewRouter()
	router.Use(di.Middleware)
	router.Path("/").HandlerFunc(di.GetInstance("indexController").(*controllers.IndexController).Log)
	router.Path("/weather").Queries("city", "{*?}").HandlerFunc(di.GetInstance("weatherController").(*controllers.WeatherController).Weather)
	_ = http.ListenAndServe(":8080", router)
}
```

## Okaaay... More examples?

Please, take a look at the [unit-tests](https://github.com/goioc/di/blob/master/di_test.go) for more examples.


goioc/di

GoLobby Container is a lightweight yet powerful IoC dependency injection container for the Go programming language

[![Go Reference](https://pkg.go.dev/badge/github.com/golobby/container.svg)](https://pkg.go.dev/github.com/golobby/container)
[![CI](https://github.com/golobby/container/actions/workflows/ci.yml/badge.svg)](https://github.com/golobby/container/actions/workflows/ci.yml)
[![CodeQL](https://github.com/golobby/container/actions/workflows/codeql-analysis.yml/badge.svg)](https://github.com/golobby/container/actions/workflows/codeql-analysis.yml)
[![Go Report Card](https://goreportcard.com/badge/github.com/golobby/container)](https://goreportcard.com/report/github.com/golobby/container)
[![Coverage Status](https://coveralls.io/repos/github/golobby/container/badge.svg)](https://coveralls.io/github/golobby/container?branch=master)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)  

# Container
GoLobby Container is a lightweight yet powerful IoC (dependency injection) container for Go projects.
It's built neat, easy-to-use, and performance-in-mind to be your ultimate requirement.

Features:
- Singleton and Transient bindings
- Named dependencies (bindings)
- Resolve by functions, variables, and structs
- Must helpers that convert errors to panics
- Optional lazy loading of bindings
- Global instance for small applications
- 100% Test coverage!

## Documentation
### Required Go Versions
It requires Go `v1.11` or newer versions.

### Installation
To install this package, run the following command in your project directory.

```bash
go get github.com/golobby/container/v3
```

Next, include it in your application:

```go
import "github.com/golobby/container/v3"
```

### Introduction
GoLobby Container is used to bind abstractions to their implementations.
Binding is the process of introducing appropriate concretes (implementations) of abstractions to an IoC container.
In this process, you also determine the resolving type, singleton or transient.
In singleton bindings, the container provides an instance once and returns it for all the requests.
In transient bindings, the container always returns a brand-new instance for each request.
After the binding process, you can ask the IoC container to make the appropriate implementation of the abstraction that your code needs.
Then your code will depend on abstractions, not implementations!

### Quick Start
The following example demonstrates a simple binding and resolving.

```go
// Bind Config interface to JsonConfig struct
err := container.Singleton(func() Config {
    return &JsonConfig{...}
})

var c Config
err := container.Resolve(&c)
// `c` will be the instance of JsonConfig
```

### Typed Binding
#### Singleton
The following snippet expresses singleton binding.

```go
err := container.Singleton(func() Abstraction {
  return Implementation
})

// If you might return an error...

err := container.Singleton(func() (Abstraction, error) {
  return Implementation, nil
})
```

It takes a resolver (function) whose return type is the abstraction and the function body returns the concrete (implementation).

The example below shows a singleton binding.

```go
err := container.Singleton(func() Database {
  return &MySQL{}
})
```

#### Transient
The example below shows a transient binding.

```go
err := container.Transient(func() Shape {
  return &Rectangle{}
})
```

### Named Bindings
You may have different concretes for an abstraction.
In this case, you can use named bindings instead of typed bindings.
Named bindings take the dependency name into account as well.
The rest is similar to typed bindings.
The following examples demonstrate some named bindings.

```go
// Singleton
err := container.NamedSingleton("square", func() Shape {
    return &Rectangle{}
})
err := container.NamedSingleton("rounded", func() Shape {
    return &Circle{}
})

// Transient
err := container.NamedTransient("sql", func() Database {
    return &MySQL{}
})
err := container.NamedTransient("noSql", func() Database {
    return &MongoDB{}
})
```

### Resolver Errors

The process of creating concrete (resolving) might face an error.
In this case, you can return the error as the second return value like the example below.

```go
err := container.Transient(func() (Shape, error) {
  return nil, errors.New("my-app: cannot create a Shape implementation")
})
```

It could be applied to other binding types.

### Resolving
Container resolves the dependencies with the `Resolve()`, `Call()`, and `Fill()` methods.

#### Using References
The `Resolve()` method takes reference of the abstraction type and fills it with the appropriate concrete.

```go
var a Abstraction
err := container.Resolve(&a)
// `a` will be an implementation of the Abstraction
```

Example of resolving using references:

```go
var m Mailer
err := container.Resolve(&m)
// `m` will be an implementation of the Mailer interface
m.Send("contact@miladrahimi.com", "Hello Milad!")
```

Example of named-resolving using references:

```go
var s Shape
err := container.NamedResolve(&s, "rounded")
// `s` will be an implementation of the Shape that named rounded
```

#### Using Closures
The `Call()` method takes a receiver (function) with arguments of abstractions you need.
It calls it with parameters of appropriate concretes.

```go
err := container.Call(func(a Abstraction) {
    // `a` will be an implementation of the Abstraction
})
```

Example of resolving using closures:

```go
err := container.Call(func(db Database) {
  // `db` will be an implementation of the Database interface
  db.Query("...")
})
```

You can also resolve multiple abstractions like the following example:

```go
err := container.Call(func(db Database, s Shape) {
  db.Query("...")
  s.Area()
})
```

You are able to raise an error in your receiver function, as well.

```go
err := container.Call(func(db Database) error {
  return db.Ping()
})
// err could be `db.Ping()` error.
```

Caution: The `Call()` method does not support named bindings.

#### Using Structs
The `Fill()` method takes a struct (pointer) and resolves its fields.

The example below expresses how the `Fill()` method works.

```go
type App struct {
    mailer Mailer   `container:"type"`
    sql    Database `container:"name"`
    noSql  Database `container:"name"`
    other  int
}

myApp := App{}

err := container.Fill(&myApp)

// [Typed Bindings]
// `myApp.mailer` will be an implementation of the Mailer interface

// [Named Bindings]
// `myApp.sql` will be a sql implementation of the Database interface
// `myApp.noSql` will be a noSql implementation of the Database interface

// `myApp.other` will be ignored since it has no `container` tag
```

#### Binding time
You can resolve dependencies at the binding time if you need previous dependencies for the new one.

The following example shows resolving dependencies at binding time.

```go
// Bind Config to JsonConfig
err := container.Singleton(func() Config {
    return &JsonConfig{...}
})

// Bind Database to MySQL
err := container.Singleton(func(c Config) Database {
    // `c` will be an instance of `JsonConfig`
    return &MySQL{
        Username: c.Get("DB_USERNAME"),
        Password: c.Get("DB_PASSWORD"),
    }
})
```

### Standalone Instance
By default, the Container keeps your bindings in the global instance.
Sometimes you may want to create a standalone instance for a part of your application.
If so, create a standalone instance like the example below.

```go
c := container.New()

err := c.Singleton(func() Database {
    return &MySQL{}
})

err := c.Call(func(db Database) {
    db.Query("...")
})
```

The rest stays the same.
The global container is still available.

### Must Helpers

You might believe that the container shouldn't raise any error and/or you prefer panics.
In this case, Must helpers are for you.
Must helpers are global methods that panic instead of returning errors.

```go
c := container.New()
// Global instance:
// c := container.Global

container.MustSingleton(c, func() Shape {
    return &Circle{a: 13}
})

container.MustCall(c, func(s Shape) {
    // ...
})

// Other Must Helpers:
// container.MustSingleton()
// container.MustSingletonLazy()
// container.MustNamedSingleton()
// container.MustNamedSingletonLazy()
// container.MustTransient()
// container.MustTransientLazy()
// container.MustNamedTransient()
// container.MustNamedTransientLazy()
// container.MustCall()
// container.MustResolve()
// container.MustNamedResolve()
// container.MustFill()
```

### Lazy Binding
Both the singleton and transient binding calls have a lazy version.
Lazy versions defer calling the provided resolver function until the first call.
For singleton bindings, It calls the resolver function only once and stores the result.

Lazy binding methods:
* `container.SingletonLazy()`
* `container.NamedSingletonLazy()`
* `container.TransientLazy()`
* `container.NamedTransientLazy()`

### Performance
The package Container inevitably uses reflection for binding and resolving processes. 
If performance is a concern, try to bind and resolve the dependencies where it runs only once, like the main and init functions.

## License

GoLobby Container is released under the [MIT License](http://opensource.org/licenses/mit-license.php).


GoLobby/Container

Additive dependency injection container for Golang

# Alice 

[![Release](https://img.shields.io/github/release/magic003/alice.svg?style=flat)](https://github.com/magic003/alice/releases/latest)
[![GoDoc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat)](https://godoc.org/github.com/magic003/alice)
[![Build Status](https://travis-ci.org/magic003/alice.png?branch=master)](https://travis-ci.org/magic003/alice)
[![Coverage Status](https://coveralls.io/repos/github/magic003/alice/badge.svg?branch=master)](https://coveralls.io/github/magic003/alice?branch=master)
[![Go Report Card](https://goreportcard.com/badge/github.com/magic003/alice?style=flat)](https://goreportcard.com/report/github.com/magic003/alice)

Alice is an additive dependency injection container for Golang.

## Philosophy

Design philosophy behind Alice:
* The application components should **not** be aware of the existence of a DI container.
* Use static Go files to define the object graph.
* Developer has the freedom to choose the way to initialize objects.

## Install

```
$ go get github.com/magic003/alice
```

## Usage

Alice is inspired by the design of [Spring JavaConfig](http://docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/). 

It usually takes 3 steps to use Alice.

### Define modules

The instances to be managed by the container are defined in modules. There could be multiple modules organized by the functionality of the instances. Modules are usually placed in a separate package.

A typical module looks like this:

```go
type ExampleModule struct {
    alice.BaseModule
    Foo Foo `alice:""`
    Bar Bar `alice:"Bar"`
    Baz Baz
}

func (m *ExampleModule) InstanceX() X {
    return X{m.Foo}
}

func (m *ExampleModule) InstanceY() Y {
    return Y{m.Baz}
}
```

A module struct must embed the `alice.BaseModule` struct. It allows 3 types of fields:
* Field tagged by `alice:""`. It will be associated with the same or assignable type of instance defined in other modules.
* Field tagged by `alice:"Bar"`. It will be associated with the instance named `Bar` defined in other modules.
* Field without `alice` tag. It will **not** be associated with any instance defined in other modules. It is expected to be provided when initializing the module. It is not managed by the container and could not be retrieved.

It is also common that no field is defined in a module struct.

Any public method of the module struct defines one instance to be intialized and maintained by the container. It is required to use a pointer receiver. The method name will be used as the instance name. The return type will be used as the instance type. Inside the method, it could use any field of the module struct to create new instances.

### Create container

During the bootstrap of the application, create a container by providing instances of modules.

```go
m1 := &ExampleModule1{}
m2 := &ExampleModule2{...}
container := alice.CreateContainer(m1, m2)
```

It will panic if any module is invalid.

### Retreive instances

The container provides 2 ways to retrieve instances: by name and by type.

```go
instanceX := container.InstanceByName("InstanceX")

instanceY := container.Instance(reflect.TypeOf((Y)(nil)))
```

It will panic either if no instance is found or if multiple matched types are found.

## Example

A dummy [example](https://github.com/magic003/alice/tree/master/example) using Alice.


alice

A dependency injection container for go programming language

# DI

[![Documentation](https://img.shields.io/badge/godoc-reference-blue.svg?style=for-the-badge&logo=go)](https://pkg.go.dev/github.com/defval/di)
[![GitHub release (latest by date)](https://img.shields.io/github/v/release/defval/di?logo=semver&style=for-the-badge)](https://github.com/defval/di/releases/latest)
[![GitHub Workflow Status (with branch)](https://img.shields.io/github/actions/workflow/status/defval/di/go.yml?branch=master&logo=github-actions&style=for-the-badge)](https://github.com/defval/di/actions/workflows/go.yml)
[![Go Report Card](https://img.shields.io/badge/go%20report-A%2B-green?style=for-the-badge)](https://goreportcard.com/report/github.com/defval/di)
[![Codecov](https://img.shields.io/codecov/c/github/defval/di?logo=codecov&style=for-the-badge)](https://codecov.io/gh/defval/di)

**DI** is a dependency injection library for the Go programming language.

Dependency injection is a form of inversion of control that increases modularity and extensibility in your programs.
This library helps you organize responsibilities in your codebase and makes it easy to combine low-level implementations
into high-level behavior without boilerplate.

## Features

- Intuitive auto wiring
- Interface implementations
- Constructor injection
- Optional injection
- Field injection
- Lazy-loading
- Tagging
- Grouping
- Iteration
- Decoration
- Cleanup
- Container Chaining / Scopes

## Installation

```shell
go get github.com/defval/di
```

## Documentation

You can use the standard [pkg.go.dev](https://pkg.go.dev/github.com/defval/di) and inline code comments. If you are new
to auto-wiring libraries such as [google/wire](https://github.com/google/wire)
or [uber-go/dig](https://github.com/uber-go/dig), start with the [tutorial](./docs/tutorial.md).

### Essential Reading

- [Tutorial](./docs/tutorial.md)
- [Examples](./_examples)
- [Advanced Features](./docs/advanced.md)

## Example Usage

```go
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"

	"github.com/defval/di"
)

func main() {
	di.SetTracer(&di.StdTracer{})
	// create container
	c, err := di.New(
		di.Provide(NewContext),  // provide application context
		di.Provide(NewServer),   // provide http server
		di.Provide(NewServeMux), // provide http serve mux
		// controllers as []Controller group
		di.Provide(NewOrderController, di.As(new(Controller))),
		di.Provide(NewUserController, di.As(new(Controller))),
	)
	// handle container errors
	if err != nil {
		log.Fatal(err)
	}
	// invoke function
	if err := c.Invoke(StartServer); err != nil {
		log.Fatal(err)
	}
}
```

Full code available [here](./_examples/tutorial/main.go).

## Questions

If you have any questions, feel free to create an issue.


A high-performance Go framework inspired by Spring Boot, offering DI, auto-configuration, and lifecycle management while maintaining Go's simplicity and efficiency

Go-Spring

Microsoft-style dependency injection for Go with scoped lifetimes and generics

# godi

[![Go Reference](https://pkg.go.dev/badge/github.com/junioryono/godi/v4.svg)](https://pkg.go.dev/github.com/junioryono/godi/v4)
[![Go Report Card](https://goreportcard.com/badge/github.com/junioryono/godi)](https://goreportcard.com/report/github.com/junioryono/godi)
[![Build Status](https://github.com/junioryono/godi/actions/workflows/test.yml/badge.svg)](https://github.com/junioryono/godi/actions/workflows/test.yml)
[![Coverage](https://codecov.io/gh/junioryono/godi/branch/main/graph/badge.svg)](https://codecov.io/gh/junioryono/godi)
[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)

**Dependency injection for Go with service lifetimes.** godi automatically wires your application, manages service lifetimes, and handles cleanup - so you can focus on business logic.

```go
services := godi.NewCollection()
services.AddSingleton(NewDatabase)     // One instance, shared everywhere
services.AddScoped(NewUserService)     // One instance per request
services.AddTransient(NewEmailBuilder) // New instance every time

provider, _ := services.Build()
user := godi.MustResolve[*UserService](provider)
```

## Why godi?

**The problem:** As applications grow, manually wiring dependencies becomes painful. Constructor parameters multiply, initialization order matters, and per-request isolation requires careful scope management.

```go
// Manual wiring - gets messy fast
config := NewConfig()
logger := NewLogger(config)
db := NewDatabase(config, logger)
cache := NewCache(config, logger)
userRepo := NewUserRepository(db, cache, logger)
orderRepo := NewOrderRepository(db, cache, logger)
userService := NewUserService(userRepo, logger)
orderService := NewOrderService(orderRepo, userService, logger)
// ... 20 more lines
```

**The solution:** Register constructors. godi figures out the rest.

```go
// godi - register in any order, resolve anything
services := godi.NewCollection()
services.AddSingleton(NewConfig)
services.AddSingleton(NewLogger)
services.AddSingleton(NewDatabase)
services.AddScoped(NewUserService)
// ... godi handles the wiring
```

## Installation

```bash
go get github.com/junioryono/godi/v4
```

Requires **Go 1.21+**. Zero external dependencies.

## Quick Start

```go
package main

import (
    "fmt"
    "github.com/junioryono/godi/v4"
)

type Logger struct{}
func (l *Logger) Log(msg string) { fmt.Println(msg) }
func NewLogger() *Logger { return &Logger{} }

type UserService struct {
    logger *Logger
}
func NewUserService(logger *Logger) *UserService {
    return &UserService{logger: logger}
}
func (s *UserService) Greet() { s.logger.Log("Hello from UserService!") }

func main() {
    // 1. Register services
    services := godi.NewCollection()
    services.AddSingleton(NewLogger)
    services.AddSingleton(NewUserService)

    // 2. Build the container
    provider, _ := services.Build()
    defer provider.Close()

    // 3. Resolve and use - dependencies wired automatically
    users := godi.MustResolve[*UserService](provider)
    users.Greet() // Hello from UserService!
}
```

## Service Lifetimes

godi provides three lifetimes to control when instances are created:

```
┌──────────────────────────────────────────────────────────────────┐
│  Application                                                     │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │ SINGLETON: Database, Logger, Config                        │  │
│  │ Created once, shared everywhere                            │  │
│  └────────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐            │
│  │  Request 1   │  │  Request 2   │  │  Request 3   │            │
│  │   SCOPED:    │  │   SCOPED:    │  │   SCOPED:    │            │
│  │  Transaction │  │  Transaction │  │  Transaction │            │
│  │  UserSession │  │  UserSession │  │  UserSession │            │
│  └──────────────┘  └──────────────┘  └──────────────┘            │
└──────────────────────────────────────────────────────────────────┘
```

| Lifetime    | Created        | Shared       | Use Case                      |
| ----------- | -------------- | ------------ | ----------------------------- |
| `Singleton` | Once           | App-wide     | Database pools, config        |
| `Scoped`    | Once per scope | Within scope | Request context, transactions |
| `Transient` | Every time     | Never        | Builders, temp objects        |

```go
services.AddSingleton(NewDatabasePool)  // One pool for the whole app
services.AddScoped(NewTransaction)      // Fresh transaction per request
services.AddTransient(NewQueryBuilder)  // New builder every resolution
```

## HTTP Integration

godi shines in web applications where each request needs isolated services:

```go
package main

import (
    "net/http"
    "github.com/junioryono/godi/v4"
    godihttp "github.com/junioryono/godi/v4/http"
)

type UserController struct {
    // Dependencies injected automatically
}

func (c *UserController) List(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte(`["alice", "bob"]`))
}

func main() {
    services := godi.NewCollection()
    services.AddSingleton(NewLogger)
    services.AddScoped(NewUserController)

    provider, _ := services.Build()
    defer provider.Close()

    mux := http.NewServeMux()
    mux.HandleFunc("GET /users", godihttp.Handle((*UserController).List))

    // ScopeMiddleware creates a fresh scope per request
    handler := godihttp.ScopeMiddleware(provider)(mux)
    http.ListenAndServe(":8080", handler)
}
```

### Framework Support

| Framework | Package                               | Install                                      |
| --------- | ------------------------------------- | -------------------------------------------- |
| net/http  | `github.com/junioryono/godi/v4/http`  | `go get github.com/junioryono/godi/v4/http`  |
| Gin       | `github.com/junioryono/godi/v4/gin`   | `go get github.com/junioryono/godi/v4/gin`   |
| Chi       | `github.com/junioryono/godi/v4/chi`   | `go get github.com/junioryono/godi/v4/chi`   |
| Echo      | `github.com/junioryono/godi/v4/echo`  | `go get github.com/junioryono/godi/v4/echo`  |
| Fiber     | `github.com/junioryono/godi/v4/fiber` | `go get github.com/junioryono/godi/v4/fiber` |

## Features

### Interface Binding

Register concrete types as interfaces for easy testing and swapping:

```go
services.AddSingleton(NewConsoleLogger, godi.As[Logger]())

// Resolve by interface
logger := godi.MustResolve[Logger](provider)
```

### Keyed Services

Multiple implementations of the same type:

```go
services.AddSingleton(NewPrimaryDB, godi.Name("primary"))
services.AddSingleton(NewReplicaDB, godi.Name("replica"))

primary := godi.MustResolveKeyed[Database](provider, "primary")
replica := godi.MustResolveKeyed[Database](provider, "replica")
```

### Service Groups

Collect related services for batch operations:

```go
services.AddSingleton(NewEmailValidator, godi.Group("validators"))
services.AddSingleton(NewPhoneValidator, godi.Group("validators"))

validators := godi.MustResolveGroup[Validator](provider, "validators")
for _, v := range validators {
    v.Validate(input)
}
```

### Parameter Objects

Simplify constructors with many dependencies:

```go
type ServiceParams struct {
    godi.In
    DB      Database
    Cache   Cache
    Logger  Logger
    Metrics Metrics `optional:"true"`
}

func NewService(params ServiceParams) *Service {
    return &Service{db: params.DB, cache: params.Cache}
}
```

### Result Objects

Register multiple services from one constructor:

```go
type InfraResult struct {
    godi.Out
    DB     *Database
    Cache  *Cache
    Health *HealthChecker
}

func NewInfra(cfg *Config) InfraResult {
    db := connectDB(cfg)
    return InfraResult{
        DB:     db,
        Cache:  NewCache(cfg),
        Health: NewHealthChecker(db),
    }
}

// One registration, three services
services.AddSingleton(NewInfra)
```

### Modules

Organize large applications:

```go
// users/module.go
var Module = godi.NewModule("users",
    godi.AddScoped(NewUserRepository),
    godi.AddScoped(NewUserService),
)

// main.go
services.AddModules(
    infrastructure.Module,
    users.Module,
    orders.Module,
)
```

### Automatic Cleanup

Services implementing `Close() error` are cleaned up automatically:

```go
func (d *Database) Close() error {
    return d.conn.Close()
}

provider.Close() // Database.Close() called automatically
```

## Error Handling

godi validates at build time to catch problems early:

```go
provider, err := services.Build()
if err != nil {
    // Circular dependency? Missing service? Lifetime conflict?
    // The error message tells you exactly what's wrong
    log.Fatal(err)
}
```

Common errors caught at build time:

- **Circular dependencies** - `*A -> *B -> *A`
- **Missing dependencies** - `*UserService requires *Database (not registered)`
- **Lifetime conflicts** - `singleton *Cache cannot depend on scoped *RequestContext`

## Testing

Replace implementations for testing:

```go
func TestUserService(t *testing.T) {
    services := godi.NewCollection()
    services.AddSingleton(func() Database { return &MockDB{} })
    services.AddScoped(NewUserService)

    provider, _ := services.Build()
    defer provider.Close()

    scope, _ := provider.CreateScope(context.Background())
    defer scope.Close()

    svc := godi.MustResolve[*UserService](scope)
    // Test with mock database
}
```

## Comparison

| Feature                    | godi | Wire | Fx  | do  |
| -------------------------- | ---- | ---- | --- | --- |
| No code generation         | Yes  | No   | Yes | Yes |
| Service lifetimes          | Yes  | No   | No  | No  |
| Scoped services            | Yes  | No   | No  | No  |
| Build-time validation      | Yes  | Yes  | No  | No  |
| HTTP framework integration | Yes  | No   | No  | No  |
| Parameter objects          | Yes  | No   | Yes | No  |
| Automatic cleanup          | Yes  | No   | Yes | Yes |

## Performance

Benchmarks comparing godi with [dig](https://github.com/uber-go/dig) (Uber's DI, powers Fx) and [do](https://github.com/samber/do) (samber's DI).

Run on Apple M2 Max. [Source code](benchmarks/comparison_test.go).

### Singleton Resolution

| Library | ns/op | B/op | allocs/op | vs godi |
| ------- | ----: | ---: | --------: | ------: |
| godi    |    55 |    0 |         0 |      1x |
| do      |   180 |  192 |         6 |    3.3x |
| dig     |   640 |  736 |        20 |     12x |

godi uses a lock-free cache with **zero allocations**. Singletons are created at build time, so every resolution is a fast cache lookup.

### Concurrent Resolution

| Library | ns/op | B/op | allocs/op | vs godi |
| ------- | ----: | ---: | --------: | ------: |
| godi    |     7 |    0 |         0 |      1x |
| do      |   297 |  224 |         6 |     42x |
| dig     |   366 |  736 |        20 |     52x |

Under high concurrency, godi is **40-50x faster** with zero contention.

### Transient Resolution

| Library | ns/op | B/op | allocs/op |
| ------- | ----: | ---: | --------: |
| godi    |   176 |   40 |         2 |
| do      |   188 |  208 |         7 |

New instance created on each call.

### Cold Start

| Library |  ns/op |   B/op | allocs/op | vs godi |
| ------- | -----: | -----: | --------: | ------: |
| godi    | 17,500 | 21,064 |       155 |      1x |
| dig     | 36,000 | 37,665 |       549 |    2.1x |
| do      | 47,000 | 30,511 |       351 |    2.7x |

Full cycle: create container, register services, build, resolve. godi is **2x faster** than dig.

<details>
<summary>Run benchmarks yourself</summary>

```bash
cd benchmarks && go test -bench=. -benchmem
```

</details>

## Documentation

**[Full Documentation](https://godi.readthedocs.io)**

- [Getting Started](https://godi.readthedocs.io/en/latest/getting-started/) - 5-minute tutorial
- [Core Concepts](https://godi.readthedocs.io/en/latest/concepts/) - Lifetimes, scopes, modules
- [Features](https://godi.readthedocs.io/en/latest/features/) - Keyed services, groups, parameter objects
- [Integrations](https://godi.readthedocs.io/en/latest/integrations/) - Gin, Chi, Echo, Fiber, net/http
- [Guides](https://godi.readthedocs.io/en/latest/guides/) - Web apps, testing, error handling
- [API Reference](https://pkg.go.dev/github.com/junioryono/godi/v4)

## Contributing

Contributions are welcome! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

## License

MIT License - see [LICENSE](LICENSE) for details.


godi

DI container library that is focused on clean API and flexibility

[![CircleCI](https://circleci.com/gh/HnH/di/tree/master.svg?style=svg&circle-token=cd6ef5c602e0f89a80488349a1e4fbe034b8d717)](https://circleci.com/gh/HnH/di/tree/master)
[![codecov](https://codecov.io/gh/HnH/di/branch/master/graph/badge.svg)](https://codecov.io/gh/HnH/di)
[![Go Report Card](https://goreportcard.com/badge/github.com/HnH/di)](https://goreportcard.com/report/github.com/HnH/di)
[![GoDoc](https://godoc.org/github.com/HnH/di?status.svg)](https://godoc.org/github.com/HnH/di)

# Dependency injection
DI is a dependency injection library that is focused on clean API and flexibility. DI has two types of top-level abstractions: Container and Resolver.
First one is responsible for accepting constructors and implementations and creating abstraction bindings out of them.
Second implements different implementation resolution scenarios against one or more Containers.

Initially this library was heavily inspired by [GoLobby Container](https://github.com/golobby/container) but since then 
had a lot of backwards incompatible changes in structure, functionality and API.
To install DI simply run in your project directory:
```bash
go get github.com/HnH/di
```

### Container
```go
type Container interface {
    Singleton(constructor any, opts ...Option) error
    Factory(constructor any, opts ...Option) error
    Implementation(implementation any, opts ...Option) error
    ListBindings(reflect.Type) (map[string]Binding, error)
    Reset()
}
```

#### Constructors

Both `Singleton()` and `Factory()` accepts Constructor as a first argument. They have some differences in how DI handles them, but in common
both `Singleton()` and `Factory()` Constructor functions may require arguments which will be resolved against di.Container at abstraction resolution time.

Moreover, `di.WithArgs()` option may provide additional arguments to constructor that won't affect Container, but will be used just for the single binding resolution.

```go
// Here Constructor will receive context.Context provided via di.WithArgs() but will not appear in container
// You can mix Constructor arguments with both Container and WithArgs() dependencies
err = di.Singleton(func(ctx context.Context) (Abstraction) {
    return newAbstraction(ctx)
}, di.WithArgs(ctx))
```

#### Singleton
`Singleton()` method requires a constructor which will return Implementation(s) of Abstraction(s). Constructor will be called once 
and returned Implementations(s) will later always bound to Abstraction(s) on resolution requests.

```go
err = di.Singleton(func() (Abstraction, SecondAbstraction) {
    return Implementation, SecondImplementation
})

// Singleton may also accept naming option which means that returned Implementation will be available only under provided name.
err = di.Singleton(func() (Abstraction) {
    return Implementation
}, di.WithName("customName"))

// Name can be provided for each of the Implementations if there are more than one.
err = di.Singleton(func() (Abstraction, SecondAbstraction) {
    return Implementation, SecondImplementation
}, di.WithName("customName", "secondCustomName"))

// If there is only one Implementation returned you may give multiple aliases for it.
err = di.Singleton(func() (Abstraction) {
    return Implementation
}, di.WithName("customName", "secondCustomName"))


// WithFill() option calls `resolver.Fill()` on an instance right after it is created.
err = di.Singleton(func() (Abstraction) {
    return Implementation
}, di.WithFill()) // di.resolver.Fill(Implementation) will be called under the hood
```

#### Factory
`Factory()` method requires a constructor which will return exactly one Implementation of exactly one Abstraction.
Constructor will be called on each Abstraction resolution request.

```go
err = di.Factory(func() (Abstraction) {
    return Implementation
})

// Factory also optionally accepts naming option which means that returned Implementation will be available only under provided name.
err := di.Factory(func() (Abstraction) {
    return Implementation
}, di.WithName("customName"))

// Similarly to Singleton binding WithFill() option can be provided
err = di.Factory(func() (Abstraction) {
    return Implementation
}, di.WithFill()) // di.resolver.Fill(Implementation) will be called under the hood
```

#### Implementation
`Implementation()` receives ready instance and binds it to its **real** type, which means that declared abstract variable type (interface) is ignored.

```go
var circle Shape = newCircle()
err = di.Implementation(circle)

// Will return error di: no binding found for di_test.Shape
var a Shape
err = di.Resolve(&a)

// Will resolve circle.
var c *Circle
err = di.Resolve(&a)

// Also naming options can be used as everywhere.
err = di.Implementation(circle, di.WithName("customName"))
err = di.Resolve(&c, di.WithName("customName"))
```

### Resolver
```go
type Resolver interface {
    With(implementations ...any) Resolver
    Resolve(receiver any, opts ...Option) error
    Call(function any, opts ...Option) error
    Fill(receiver any) error
}
```
#### With
`With()` takes a list of instantiated implementations and tries to use them in resolving scenarios.
In the opposite to Container's `Implementation()` method `With()` does not put instances into container and does not reflect a type on a binding time.
Instead of this it reuses `reflect.Type.AssignableTo()` method capabilities on abstraction resolution time.

```go
var circle Shape = newCircle()
err = di.Implementation(circle)

// di: no binding found for di_test.Shape
di.Call(func(s Shape) { return })

// ok
di.With(circle).Call(func(s Shape) { return }))
```

#### Resolve
`Resolve()` requires a receiver (pointer) of an Abstraction and fills it with appropriate Implementation.

```go
var abs Abstraction
err = di.Resolve(&a)

// Resolution can be done with previously registered names as well
err = di.Resolve(&a, di.WithName("customName"))
```

#### Call
The `Call()` executes as `function` with resolved Implementation as a arguments.

```go
err = di.Call(func(a Abstraction) {
    // `a` will be an implementation of the Abstraction
})

// Returned values can be bound to variables by providing an option.
var db Database
err = di.Call(func(a Abstraction) Database {
    return &MySQL{a}
}, di.WithReturn(&db))
// db == &MySQL{a}
```

#### Fill
The `Fill()` method takes a struct (pointer) and resolves its fields. The example below expresses how the `Fill()` method works.

```go
err = di.Singleton(func() Mailer { return &someMailer{} })

err = di.Singleton(func() (Database, Database) {
    return &MySQL{}, &Redis{} 
}, di.WithName("data", "cache"))

type App struct {
    mailer  Mailer              `di:"type"` // fills by field type (Mailer)
    data    Database            `di:"name"` // fills by field type (Mailer) and requires binding name to be field name (data)
    cache   Database            `di:"name"`
    dbList  []Database          `di:"recursive"` // will fill slice with all available implementations of Database 
    dbMap   map[string]Database `di:"recursive"` // will fill slice with all available implementations of Database. Binding name will be used as a key

    inner   struct {
        cache Database `di:"name"`	
    } `di:"recursive"`             // instructs DI to fill struct recursively
    
    another struct {
        cache Database `di:"name"` // won't have any affect as long as outer field in App struct won't have `di:"recursive"` tag
    }
}

var App = App{}
err = container.Fill(&myApp)

// [Typed Bindings]
// `App.mailer` will be an implementation of the Mailer interface

// [Named Bindings]
// `App.data` will be a MySQL implementation of the Database interface
// `App.cache` will be a Redis implementation of the Database interface
// `App.inner.cache` will be a Redis implementation of the Database interface

// `App.another` will be ignored since it has no `di` tag
```
Notice that by default `Fill()` method returns error if unable to resolve any struct fields.
If one of the fields if optional, omitempty suffix should be added to the di tag.
```go
type App struct {
    mailer  Mailer `di:"type,omitempty"` // Fill will not return error if Mailer was not provided
}
```

Alternatively map[string]Type or []Type can be provided. It will be filled with all available implementations of provided Type.

```go
var list []Shape
container.Fill(&list)

// []Shape{&Rectangle{}, &Circle{}}

var list map[string]Shape
container.Fill(&list)

// map[string]Shape{"square": &Rectangle{}, "rounded": &Circle{}} 
```

### Provider
Provider is an abstraction of an entity that provides something to Container

```go
type Provider interface {
    Provide(Container) error
}
```

### Constructor
Constructor implements a `Construct()` method which is called either after binding to container in case of singleton, either after factory method was called.
Note that `context.Context` must be provided in container before Constructor method can be called.

```go
type Constructor interface {
    Construct(context.Context) error
}
```

### Context propagation
```go
type Context interface {
    Put(Container) Context
    Container() Container
    Resolver() Resolver
    Raw() context.Context
}
```
Context propagation is possible via `di.Context` abstraction. Quick example:
```go
var container = di.NewContainer()
container.Implementation(newCircle())

var (
    ctx = di.Ctx(context.Background).Put(container)
    shp Shape
)

err = ctx.Resolver().Resolve(&shp) // err == nil
```


HnH/di

Customizable dependency injection container with the global mode, cascade initialization and panic-safe finalization

# KInit

[![Go Reference](https://pkg.go.dev/badge/github.com/go-kata/kinit.svg)](https://pkg.go.dev/github.com/go-kata/kinit)
[![codecov](https://codecov.io/gh/go-kata/kinit/branch/master/graph/badge.svg?token=NBFR4LKON8)](https://codecov.io/gh/go-kata/kinit)
[![Report Card](https://goreportcard.com/badge/github.com/go-kata/kinit)](https://goreportcard.com/report/github.com/go-kata/kinit)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

**[Usage examples](https://github.com/go-kata/examples)**

## Installation

`go get github.com/go-kata/kinit`

## Status

**This is a beta version.** API is not stabilized for now.

## Versioning

*Till the first major release* minor version (`v0.x.0`) must be treated as a major version
and patch version (`v0.0.x`) must be treated as a minor version.

For example, changing of version from `v0.1.0` to `v0.1.1` indicates compatible changes,
but when version changes `v0.1.1` to `v0.2.0` this means that the last version breaks the API.

## How to use

This library provides the global [IoC](https://en.wikipedia.org/wiki/Inversion_of_control) container which does
the automatic [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection):

```go
kinit.Global()
```

If you need a local one (e.g. for tests), you can create it as following:

```go
ctr := kinit.NewContainer()
```

A local container must be filled up with *constructors* and *processors* manually whereas the global one
can be filled up when [initializing packages](https://golang.org/doc/effective_go.html#init).

### Constructors

Constructors are entities that create *objects* (dependencies for injection in context of the DI). They have the
following interface:

```go
type Constructor interface {
	
	Type() reflect.Type
	
	Parameters() []reflect.Type
	
	Create(a ...reflect.Value) (reflect.Value, kdone.Destructor, error)
	
}
```

Here `Type` returns a type of object to create, `Parameters` returns types of other objects required to create
this object and finally `Create` creates and returns a new object and its destructor (use`kdone.Noop`, not nil,
if object has no destructor).

To register a constructor in the container use the `Provide` method.

The container allows to have only one constructor for each type. However, the `reflect.Type` is the interface, and
you can implement it as you want, e.g. as following:

```go
type NamedType stuct {
	reflect.Type
	Name string
}
```

Just keep in mind that the container uses a simple comparison of `reflect.Type` instances when looks up for
necessary constructors (as well as processors and already created objects).

### Processors

Processors are entities that process already created objects. The container applies processors immediately after
the object creation and before an object will be injected as a dependency at the first time. Processors have the
following interface:

```go
type Processor interface {
	
	Type() reflect.Type
	
	Parameters() []reflect.Type

	Process(obj reflect.Value, a ...reflect.Value) error
	
}
```

Here `Type` returns a type of object to process, `Parameters` returns types of other objects required to process
this object and finally `Process` processes an object.

To register a processor in the container use the `Attach` method.

The container allows to have an unlimited number of processors for each type but doesn't guarantee the order of
their calling.

### Functors

Functors represent functions to be run in the container and have the following interface:

```go
type Functor interface {
	
	Parameters() []reflect.Type
	
	Call(a ...reflect.Value) ([]Functor, error)
	
}
```

Here `Parameters` returns types of objects required to call a function and `Call` calls a function and may return
*further functors*.

To run functors in the container use the `Run` method.

At the start of run the container creates so-called *arena* that holds all created objects (only one object
for each type). If some object required as a dependency is already on the arena it will be used, otherwise
it will be firstly created and processed. All objects that are on the arena at the end of run will be
automatically destroyed.

The container runs given functors sequentially. Their dependencies are resolved recursively using registered
constructors and processors. If functor (let's call it *branched*) returns further functors, the container runs
all of them before continue running functors following the branched one. This is called the *Depth-First Run*.
  
## KInitX

[![Go Reference](https://pkg.go.dev/badge/github.com/go-kata/kinit/kinitx.svg)](https://pkg.go.dev/github.com/go-kata/kinit/kinitx)

This subpackage provides the expansion set includes default handy implementations of main library interfaces
along with other handy tools. In most cases the **KInitX** is all you need to use the entire **KInit** functionality.

There are following implementations:

**Constructor** represents a constructor based on a function. It accepts `func(...) T`, `func(...) (T, error)` and
`func(...) (T, kdone.Destructor, error)` signatures where `T` is an arbitrary Go type.

```go
kinitx.MustProvide(func(config *Config) (*Object, kdone.Destructor, error) { ... })
```

**Opener** represents a constructor based on a function that creates an implementation of the `io.Closer` interface.
It accepts `func(...) C` and `func(...) (C, error)` signatures where `C` is an arbitrary implementation of the
`io.Closer` interface.

```go
kinitx.MustProvide(func(logger *log.Logger) (*sql.DB, error) { ... })
```

**Initializer** represents a memberwise initializer of a struct. It accepts a template struct like a `YourType{}`
and a template struct pointer like a `(*YourType)(nil)` or `new(YourType)`.

```go
kinitx.MustProvide((*Config)(nil))
```

**Binder** represents a pseudo-constructor that casts an object to an interface. It accepts an interface pointer
like a `(*YourInterface)(nil)`.

```go
kinitx.MustBind((*StorageInterface)(nil), (*PostgresStrorage)(nil))
```

**Processor** represents a processor based on a function. It accepts `func(T, ...)` and `func(T, ...) error`
signatures where `T` is an arbitrary Go type.

```go
kinitx.MustAttach((*Object).SetOptionalProperty)
```

**Functor** represents a functor based on a function. It accepts `func(...)`, `func(...) error`,
`func(...) (kinit.Functor, error)` and `func(...) ([]kinit.Functor, error)` signatures.

```go
kinitx.MustRun(func(app *Application) error { ... })
```

## KInitQ

[![Go Reference](https://pkg.go.dev/badge/github.com/go-kata/kinit/kinitq.svg)](https://pkg.go.dev/github.com/go-kata/kinit/kinitq)

The DI mechanism provided by the main library is reflection-based and works in the runtime. However, this subpackage
makes it possible to validate the dependency graph semi-statically thanks to build tags.

Just add two main functions as following:

`main.go`

```go
// +build !inspect

package main

import "github.com/go-kata/kinit/kinitx"

func main() { kinitx.MustRun(EntryPoint) }
```

`main_inspect.go`

```go
// +build inspect

package main

import "github.com/go-kata/kinit/kinitx"

func main() { kinitx.MustInspect(nil) }
```

Now to validate the dependency graph of your program just run:

`go run -tags inspect`

Example output:

```
2 errors occurred:
    #1 🠖 cyclic dependency: *config.Config 🠖 config.Loader 🠖 *config.FileLoader 🠖 *config.Config
    #2 🠖 unsatisfied dependency: *sql.DB 🠖 *log.Logger
```

For more details learn the documentation and explore examples.

## Putting all together

In the [github.com/go-kata/examples](https://github.com/go-kata/examples) repository you can find examples of
how may the code uses this library looks like.

## References

**[KDone](https://github.com/go-kata/kdone)** is the library that provides tools for destroying objects.

**[KError](https://github.com/go-kata/kerror)** is the library that provides tools for handling errors.


kinit

A reflection based dependency injection and inversion of control library with components lifecycle support

# Linker

[![Go Report Card](https://goreportcard.com/badge/github.com/logrange/linker)](https://goreportcard.com/report/github.com/logrange/linker) [![codecov](https://codecov.io/gh/logrange/linker/branch/master/graph/badge.svg)](https://codecov.io/gh/logrange/linker) [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://github.com/logrange/linker/blob/master/LICENSE) [![GoDoc](https://godoc.org/github.com/logrange/linker?status.png)](https://godoc.org/github.com/logrange/linker)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge-flat.svg)](https://github.com/avelino/awesome-go)

Linker is Dependency Injection and Inversion of Control package. It supports the following features:

- Components registry
- Automatic dependency injection of the registered components
- Components lifecycle support via `PostConstructor`, `Initializer` and `Shutdowner` interfaces implementations
- Post-injection notification
- Automatic ordering of components initialization 
- Circular dependency detection
- Components shutdowning

Please refer to [this blogpost](https://www.logrange.io/blog/linker.html) for some details.

Linker is used by [Logrange](https://github.com/logrange/logrange), please take a look how it is used [there](https://github.com/logrange/logrange/blob/be1cc8dc0ae8fa9154eec91bea33cd2105509e11/server/server.go#L53).

```golang

import (
     "github.com/logrange/linker"
)

type DatabaseAccessService interface {
    RunQuery(query string) DbResult
}

// MySQLAccessService implements DatabaseAccessService
type MySQLAccessService struct {
	// Conns uses field's tag to specify injection param name(mySqlConns)
	// or sets-up the default value(32), if the param is not provided 
    Conns int `inject:"mySqlConns, optional:32"`
}

type BigDataService struct {
	// DBa has DatabaseAccessService type which value will be injected by the injector
	// in its Init() function, or it fails if there is no appropriate component with the name(dba)
	// was registered...
    DBa DatabaseAccessService `inject:"dba"`
}
...

func main() {
    // 1st step is to create the injector
    inj := linker.New()
	
    // 2nd step is to register components
    inj.Register(
		linker.Component{Name: "dba", Value: &MySQLAccessService{}},
		linker.Component{Name: "", Value: &BigDataService{}},
		linker.Component{Name: "mySqlConns", Value: int(msconns)},
		...
	)
	
	// 3rd step is to inject dependecies and initialize the registered components
	inj.Init(ctx)
	
	// the injector fails-fast, so if no panic everything is good so far.
	
	...
	// 4th de-initialize all compoments properly
	inj.Shutdown()
}

```
### Annotate fields using fields tags
The `inject` tag field has the following format:
```
inject: "<name>[,optional[:<defaultValue]]"
```
So annotated fields can be assigned using different rules:
```golang
// Field will be assigned by component with registration name "compName",
// if there is no comonent with the name, or it could not be assigned to the type 
// FieldType, panic will happen
Field FieldType `inject:"compName"`

// Field will be assigned by component with any name (indicated as ""), which could be 
// assigned to the FieldType. If no such component or many matches to the type, 
// panic will happen.
Field FieldType `inject:""`

// If no components match to either Field1 or Field2 they will be skipped with 
// no panic. Ambigious situation still panics
Field1 FieldType `inject:"aaa, optional"`
Field2 FieldType `inject:", optional"`

// Default values could be provided for numeric and string types. The 
// default values will be assigned if no components match to the rules
NumFld int `inject:"intFld, optional: 21"`
StrFld string `inject:"strFld,optional:abc"`
```
### Create the injector
Injector is a main object, which  controls the components: registers them, initializes, checks and provides initialization and shutdown calls.
```golang
inj := linker.New()
```
### Register components using names or anonymously
Component is an object that can be used for initialization of other components, or which requires an initialization. Components can have different types, but only fields of components, with 'pointer to struct' type, could be assigned by the Injector. Injector is responsible for the injection(initialization a component's fields) process. All components must be registered in injector via `Register()` function before the initialization process will be run.
### Initialize components
When all components are registered `Init()` function of the `Injector` allows to perform initialization. The `Init()` function does the following actions:
1. Walks over all registered components and assigns all tagged fields using named and unnamed components. If no matches or ambiguity happens, the `Init()` can panic.
2. For components, which implement [linker.PostConstructor](https://github.com/logrange/linker/blob/5dbea0d87b81a70e721f6c359d5f28dc1a01e080/inject.go#L74) interface, the `PostConstruct()` function will be called.
3. For components, which implements [linker.Initializer](https://github.com/logrange/linker/blob/5dbea0d87b81a70e721f6c359d5f28dc1a01e080/inject.go#L90) interface, the `Init(ctx)` function will be called in a specific order. The initialization order is defined as following: less dependent components are initialized before the components 
4. If circular dependency between registered components is found, Init() will panic.
### Shutting down registered components properly
Properly initialized components could be shut-down in back-initialization order by calling `Shutdown()` function of the injector. Components, that implement [linker.Shutdowner](https://github.com/logrange/linker/blob/5dbea0d87b81a70e721f6c359d5f28dc1a01e080/inject.go#L108) interface, will be called by the `Shutdown()`


linker

Strict Runtime Dependency Injection for Golang

# wire

[![GoDoc](https://godoc.org/github.com/Fs02/wire?status.svg)](https://godoc.org/github.com/Fs02/wire) [![Build Status](https://travis-ci.org/Fs02/wire.svg?branch=master)](https://travis-ci.org/Fs02/wire) [![Go Report Card](https://goreportcard.com/badge/github.com/Fs02/wire)](https://goreportcard.com/report/github.com/Fs02/wire) [![Maintainability](https://api.codeclimate.com/v1/badges/7957f2fe0d2c6fd5d72c/maintainability)](https://codeclimate.com/github/Fs02/wire/maintainability) [![Test Coverage](https://api.codeclimate.com/v1/badges/7957f2fe0d2c6fd5d72c/test_coverage)](https://codeclimate.com/github/Fs02/wire/test_coverage)
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2FFs02%2Fwire.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2FFs02%2Fwire?ref=badge_shield)

Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency injected.

Features:

- Strictly validates dependency and prevents missing or ambiguous dependency.
- Check againts possible forgotten `wire` tag.
- Easily connect and resolve object anywhere.
- Annotates ambiguous interface type using connection name or implementation name.

## Install

```bash
go get github.com/Fs02/wire
```

## Example

```golang
package wire_test

import (
	"fmt"

	"github.com/Fs02/wire"
)

type Listener struct{}

func (listener Listener) Next() string {
	return "system"
}

type Printer interface {
	Exec(string) error
}

type SystemPrint struct {
	App string `wire:""`
}

func (systemPrint SystemPrint) Exec(msg string) error {
	fmt.Println("[" + systemPrint.App + "] System: " + msg)
	return nil
}

type UserPrint struct {
	App    string `wire:""`
	Target string
}

func (userPrint UserPrint) Exec(msg string) error {
	fmt.Println("[" + userPrint.App + "]" + userPrint.Target + ": " + msg)
	return nil
}

type Service struct {
	// Each of `wire`` tag below indicate fields to be wired with apporpriate component.
	// value inside `wire` tag indicate the name of the component and optionally it's type.
	// `wire` with empty value will be wired with default value (named using empty string).
	// Ambiguous field can be resolved by adding it's type, name or both (separated using comma) to the `wire` tag.
	// Don't worry if you forgot to add wire tag to an interface or a pointer, wire will warn you if any nil field are found.
	// To ignore wiring on specific field, you can use add `wire:"-"`.
	Listener     Listener `wire:""`
	SystemPrint  Printer  `wire:",SystemPrint"`
	FooUserPrint Printer  `wire:"foo"`
	BooUserPrint Printer  `wire:"boo,UserPrint"`
}

func (service Service) Update() error {
	switch service.Listener.Next() {
	case "system":
		return service.SystemPrint.Exec("hello from system")
	case "user-foo":
		return service.FooUserPrint.Exec("hello from foo")
	case "user-boo":
		return service.BooUserPrint.Exec("hello from boo")
	default:
		return nil
	}
}

func init() {
	// add components to be wired by the library.
	// wire all components only once and as early as possible.
	wire.Connect("CoolApp")
	wire.Connect(Listener{})                       // we don't need to pass by reference here, since it doesn't require any wiring.
	wire.Connect(&SystemPrint{})                   // we need to pass by reference it to allow wiring, wire will panic if we pass by value.
	wire.Connect(&UserPrint{Target: "foo"}, "foo") // wire a UserPrint named by "foo".
	wire.Connect(&UserPrint{Target: "boo"}, "boo") // wire a UserPrint named by "boo", wire will panic if there's duplicate components detected.
	wire.Connect(&Service{})

	// Apply wiring
	wire.Apply()
}

func Example() {
	// Resolve a service component to be used later.
	var service Service
	wire.Resolve(&service)

	service.Update()
	// Output: [CoolApp] System: hello from system
}
```

## License

Released under the [MIT License](https://github.com/Fs02/wire/blob/master/LICENSE)


[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2FFs02%2Fwire.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2FFs02%2Fwire?ref=badge_large)

wire

A flexible and modular reflection-based DI library with advanced features like scoped contexts and proxy generation, designed for large-scale Go applications

[![CI](https://github.com/matzefriedrich/parsley/actions/workflows/go.yml/badge.svg)](https://github.com/matzefriedrich/parsley/actions/workflows/go.yml)
[![Coverage Status](https://coveralls.io/repos/github/matzefriedrich/parsley/badge.svg)](https://coveralls.io/github/matzefriedrich/parsley)
[![Go Reference](https://pkg.go.dev/badge/github.com/matzefriedrich/parsley.svg)](https://pkg.go.dev/github.com/matzefriedrich/parsley)
[![Go Report Card](https://goreportcard.com/badge/github.com/matzefriedrich/parsley)](https://goreportcard.com/report/github.com/matzefriedrich/parsley)
![License](https://img.shields.io/github/license/matzefriedrich/parsley)
![GitHub go.mod Go version](https://img.shields.io/github/go-mod/go-version/matzefriedrich/parsley)
![GitHub Release](https://img.shields.io/github/v/release/matzefriedrich/parsley?include_prereleases)

[![FOSSA Status](https://app.fossa.com/api/projects/custom%2B48327%2Fgithub.com%2Fmatzefriedrich%2Fparsley.svg?type=shield&issueType=license)](https://app.fossa.com/projects/custom%2B48327%2Fgithub.com%2Fmatzefriedrich%2Fparsley?ref=badge_shield&issueType=license)
[![FOSSA Status](https://app.fossa.com/api/projects/custom%2B48327%2Fgithub.com%2Fmatzefriedrich%2Fparsley.svg?type=shield&issueType=security)](https://app.fossa.com/projects/custom%2B48327%2Fgithub.com%2Fmatzefriedrich%2Fparsley?ref=badge_shield&issueType=security)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go?tab=readme-ov-file#dependency-injection)


## What is Parsley?

Parsley is a reflection-based dependency injection (DI) package for Go that streamlines dependency management through automated lifetime management, type-safe registration, service resolution and activation, proxy generation, and method interception. It leverages reflection only at startup, ensuring runtime efficiency, and supports features like mocking and testing integration for better development workflows.

### Why use dependency injection in Go?

Dependency injection in Go typically relies on constructor functions, which are idiomatic and foundational for creating and managing dependencies. While this approach is powerful, it can lead to boilerplate code as projects become more complex, requiring explicit instantiation and manual wiring. Addionally, more sophisticated ramp-up code is needed, if not all instances shall be created at application start. Parsley eliminates much of this repetitive code by automating the creation and wiring of dependencies, enabling developers to focus on application logic. It aims to enhance modularity and make managing dependencies easier.

## Key Features

- **Type Registration**: Supports constructor functions, lifetime management (singleton, scoped, transient), and safe casts.  
- **Modular and Lazy Loading**: Register types as modules, resolve dependencies on-demand, and inject lazily with `Lazy[T]`.  
- **Registration Validation**: Ensures early detection of missing registrations or circular dependencies.
- **Advanced Registrations**: Register multiple implementations for the same interface using named services or lists.  
- **Proxy and Mock Support**: Generate extensible proxy types and configurable mocks to streamline testing workflows.  

For a complete overview of features and capabilities, refer to the [Parsley documentation](https://matzefriedrich.github.io/parsley-docs/).  


## Usage

### Install Parsley

Add Parsley to your project:

```sh
go get github.com/matzefriedrich/parsley
```

For advanced features like proxy generation or mock creation, install the `parsley-cli` utility:

```sh
go install github.com/matzefriedrich/parsley/cmd/parsley-cli
```

--- 

Copyright 2024 - 2025 by Matthias Friedrich


parsley

A dependency injection based application framework for Go (built on top of dig)

# :unicorn: Fx [![GoDoc](https://pkg.go.dev/badge/go.uber.org/fx)](https://pkg.go.dev/go.uber.org/fx) [![Github release](https://img.shields.io/github/release/uber-go/fx.svg)](https://github.com/uber-go/fx/releases) [![Build Status](https://github.com/uber-go/fx/actions/workflows/go.yml/badge.svg)](https://github.com/uber-go/fx/actions/workflows/go.yml) [![Coverage Status](https://codecov.io/gh/uber-go/fx/branch/master/graph/badge.svg)](https://codecov.io/gh/uber-go/fx/branch/master) [![Go Report Card](https://goreportcard.com/badge/go.uber.org/fx)](https://goreportcard.com/report/go.uber.org/fx)

Fx is a dependency injection system for Go.

**Benefits**

- Eliminate globals: Fx helps you remove global state from your application.
  No more `init()` or global variables. Use Fx-managed singletons.
- Code reuse: Fx lets teams within your organization build loosely-coupled
  and well-integrated shareable components.
- Battle tested: Fx is the backbone of nearly all Go services at Uber.

See our [docs](https://uber-go.github.io/fx/) to get started and/or
learn more about Fx.

## Installation

Use Go modules to install Fx in your application.

```shell
go get go.uber.org/fx@v1
```

## Getting started

To get started with Fx, [start here](https://uber-go.github.io/fx/get-started/).

## Stability

This library is `v1` and follows [SemVer](https://semver.org/) strictly.

No breaking changes will be made to exported APIs before `v2.0.0`.

This project follows the [Go Release Policy](https://golang.org/doc/devel/release.html#policy). Each major
version of Go is supported until there are two newer major releases.

## Stargazers over time

[![Stargazers over time](https://starchart.cc/uber-go/fx.svg)](https://starchart.cc/uber-go/fx)



🪣 gocontainer
================
[![Build Status](https://travis-ci.org/vardius/gocontainer.svg?branch=master)](https://travis-ci.org/vardius/gocontainer)
[![Go Report Card](https://goreportcard.com/badge/github.com/vardius/gocontainer)](https://goreportcard.com/report/github.com/vardius/gocontainer)
[![codecov](https://codecov.io/gh/vardius/gocontainer/branch/master/graph/badge.svg)](https://codecov.io/gh/vardius/gocontainer)
[![](https://godoc.org/github.com/vardius/gocontainer?status.svg)](https://pkg.go.dev/github.com/vardius/gocontainer)
[![license](https://img.shields.io/github/license/mashape/apistatus.svg)](https://github.com/vardius/gocontainer/blob/master/LICENSE.md)

<img align="right" height="180px" src="https://github.com/vardius/gorouter/blob/master/website/src/static/img/logo.png?raw=true" alt="logo" />

gocontainer - Dependency Injection Container

📖 ABOUT
==================================================
Contributors:

* [Rafał Lorenz](http://rafallorenz.com)

Want to contribute ? Feel free to send pull requests!

Have problems, bugs, feature ideas?
We are using the github [issue tracker](https://github.com/vardius/gocontainer/issues) to manage them.

## 📚 Documentation

For __examples__ **visit [godoc#pkg-examples](http://godoc.org/github.com/vardius/gocontainer#pkg-examples)**

For **GoDoc** reference, **visit [pkg.go.dev](https://pkg.go.dev/github.com/vardius/gocontainer)**

[MustInvokeMany](https://godoc.org/github.com/vardius/gocontainer#example-package--MustInvokeMany)

🚏 HOW TO USE
==================================================

First file `main.go` simply gets the repository from the container and prints it
we use **MustInvoke** method to simply present the way where we keep type safety
```go
package main

import (
    "github.com/vardius/gocontainer/example/repository"
    "github.com/vardius/gocontainer"
)

func main() {
    gocontainer.MustInvoke("repository.mysql", func(r Repository) {
        fmt.Println(r)
    })
}
```
Our database implementation uses `init()` function to register db service
```go
package database

import (
    "fmt"
    "database/sql"

    "github.com/vardius/gocontainer"
)

func NewDatabase() *sql.DB {
    db, _ := sql.Open("mysql", "dsn")

    return db
}

func init() {
    db := gocontainer.MustGet("db")

    gocontainer.Register("db", NewDatabase())
}
```
Our repository accesses earlier on registered db service
and following the same patter uses `init()` function to register repository service within container
```go
package repository

import (
    "fmt"
    "database/sql"

    "github.com/vardius/gocontainer"
    _ "github.com/vardius/gocontainer/example/database"
)

type Repository interface {}

func NewRepository(db *sql.DB) Repository {
    return &mysqlRepository{db}
}

type mysqlRepository struct {
    db *sql.DB
}

func init() {
    db := gocontainer.MustGet("db")

    gocontainer.Register("repository.mysql", NewRepository(db.(*sql.DB)))
}
```
You can disable global container instance by setting `gocontainer.GlobalContainer` to `nil`.
This package allows you to create many containers.
```go
package main

import (
    "github.com/vardius/gocontainer/example/repository"
    "github.com/vardius/gocontainer"
)

func main() {
    // disable global container instance
    gocontainer.GlobalContainer = nil

    mycontainer := gocontainer.New()
    mycontainer.Register("test", 1)
}
```
Please check [GoDoc](http://godoc.org/github.com/vardius/gocontainer) for more methods and examples.

📜 [License](LICENSE.md)
-------

This package is released under the MIT license. See the complete license in the package


The Best Go Libraries For Miscellaneous - Dependency Injection (24)

dig

ore