The Challenge of Manual Dependency Management in Go

In our introductory article, Part 0: The Case for Dependency Injection in Go, we discussed why managing dependencies manually becomes a significant burden as Go applications grow.

While this approach is transparent and easy to trace, it presents several challenges as the dependency graph deepens:

• Boilerplate overhead: You often find yourself writing extensive setup code in main.go to instantiate and wire dozens of services.
• Lifetime management complexity: Ensuring that a database pool is a singleton while a request logger is scoped to a specific transaction requires careful manual tracking.
• Refactoring friction: Adding a new dependency to a low-level service requires updating every intermediate factory function in the chain.

You may have evaluated tools like google/wire for compile-time generation or uber-go/dig for runtime reflection-based injection. Parsley provides a balanced, reflection-based alternative designed to bridge the gap between simple configuration and automated service activation.

Introduction to Parsley

Parsley is a reflection-based dependency injection package for Go, hosted on GitHub, that implements the Inversion of Control (IoC) principle. It allows you to define how your services should be created and let the framework handle the wiring and lifetime management.

Unlike code-generation tools that can clutter your workspace, Parsley works at runtime, providing flexibility without requiring additional build steps. It is particularly well-suited for developers transitioning from ecosystems like C# (.NET) or Java (Spring) who value a clear, registry-based approach to DI.

Architectural Overview

Parsley centers around two primary concepts:

1. The Service Registry: A container where you define service mappings, constructor functions, and lifetime behaviors.
2. The Resolver: The component that traverses the dependency graph and instantiates services as needed.

Parsley supports three distinct lifetime behaviors:

• Singleton: A single instance is created and shared across the entire application.
• Scoped: An instance is created once per scope (e.g., per HTTP request).
• Transient: A new instance is created every time the service is requested.

Practical Example: A Simple Greeter

To see Parsley in action, let's build a simple application that greets the user.

1. Define the Abstraction

We start by defining a Greeter interface. This follows the Go practice of defining contracts at the consumer level (or close to it) to enable decoupling.

type Greeter interface {
    Greet(name string) string
}

2. Implement the Service

We implement a concrete greeter type. The struct can remain unexported because it will be instantiated via a constructor function that returns the exported interface.

type greeter struct{}

func (s *greeter) Greet(name string) string {
    return fmt.Sprintf("Hello, %s!", name)
}

func NewGreeter() Greeter {
    return &greeter{}
}

3. Register and Resolve the Service

The following example demonstrates how to set up the registry, register the service as transient, and resolve it using the resolving package.

package main

import (
    "context"
    "fmt"

    "github.com/matzefriedrich/parsley/pkg/registration"
    "github.com/matzefriedrich/parsley/pkg/resolving"
)

func main() {
    // Initialize the registry
    registry := registration.NewServiceRegistry()

    // Register the constructor function
    _ = registration.RegisterTransient(registry, NewGreeter)

    // Create a resolver and a scope
    resolver := resolving.NewResolver(registry)
    ctx := context.Background()
    scope := resolving.NewScopedContext(ctx)

    // Resolve the Greeter service
    greeterService, err := resolving.ResolveRequiredService[Greeter](scope, resolver)
    if err != nil {
        panic(err)
    }

    fmt.Println(greeterService.Greet("Parsley"))
}

Operational Considerations

When adopting a reflection-based DI container like Parsley, keep the following operational concerns in mind:

• Error Handling: Parsley encourages explicit error handling. While the registry functions return errors, you should also ensure your constructor functions return errors if they can fail during initialization.
• Startup Performance: Reflection has a minor performance cost at startup. For most backend applications, this is negligible compared to database connections or network initialization, but it should be measured in latency-sensitive environments.
• Context Management: Always use NewScopedContext to ensure that scoped services are properly tracked and disposed of if they implement any cleanup logic.

Tradeoffs and Limitations

Parsley is designed for simplicity and ease of use, but it involves tradeoffs common to reflection-based DI:

• Runtime vs. Compile-time: Unlike wire, Parsley cannot catch missing dependencies at compile-time. You should use Parsley's built-in validation features (which we will cover in a later part of this series) during your CI/CD process or application startup.
• Reflection: While Go's reflection is efficient, it is still slower than direct instantiation. Parsley optimizes this by caching resolution plans, but the very first resolution of a type will incur a small overhead.

Summary

Parsley offers a robust way to implement Inversion of Control in Go applications without the complexity of code generation. By leveraging constructor functions and automated lifetime management, it reduces boilerplate and allows developers to focus on business logic rather than wiring.

In the next part of this series, we will dive deeper into Service Registration Fundamentals, exploring how to register preexisting instances and handle more complex constructor signatures.

Next Steps

• Explore the Parsley Documentation on GitHub.
• Experiment with different lifetimes (Singleton vs. Scoped) in your own projects.