Eliminating globals -- what's the right pattern?

[debedb]

One of the tenets of this library is:

Eliminate globals: Fx helps you remove global state from your application. No more init() or global variables. Use Fx-managed singletons.

My question is, what is the blessed pattern to keep some things that are indeed global (say, in my application, it is a config object and logger)? I am currently using Fx to populate a struct containing them but it is a global var in a package, which doesn't seem like the best way. What are some best practices?

[abhinav]

Hey @debedb. The idea is to use Fx to build the configuration object, the logger, and the application. All such dependencies should be parameters to the constructor, and the constructors should be orchestrated through fx.Provide, fx.Invoke, and friends. The only time fx.Populate should be used is in tests, or when you need to break out of the Fx injection model.

Hypothetically, from what you're suggesting, you might have a function to load configuration, and one to build a logger from that configuration:

func LoadConfig() (*Config, error) { /* ... */ }

func NewLogger(*Config) *Logger { /* ... */ }

With Fx, you won't call the constructors directly. You'll fx.Provide them to fx.New in any order:

fx.New(
  fx.Provide(
    LoadConfig,
    NewLogger,
  ),
)

Fx will inspect their signatures and match the *Config return value to the *Config parameter. Similarly, you'll provide Fx something to build your application, say:

func NewApplication(*Config, *Logger) *App

// And then in fx.New:

fx.New(
  fx.Provide(
    // ..
    NewApplication,
  ),
)

Finally, fx.Provide just tells everything "how to build things" but it doesn't yet build anything. To actually do something, you have to tell Fx what you want to actually run. For example, if *App has a method to start it:

// Start starts the application in a background goroutine,
// listening on the port specified in Config.
func (*App) Start() error

Then you'll add an fx.Invoke to run that in an "start hook".
This makes use of Fx's lifecycle hooks:

fx.New(
  // ...
  fx.Invoke(func(app *App, lc fx.Lifecycle) error {
    lc.Append(fx.Hook{
      OnStart: func(context.Context) error {
        return app.Start()
      },
    })
  }),
)

// There's also a "stop" lifecycle hook that I've omitted above.

// I agree that the hooks API is a bit verbose;
// Fx now includes a better way to do that,
// but I wanted to avoid introducing new concepts right now.

Following that, you have to just Run your fx.App:

fx.New(
  // ...
).Run()

Fx will block until you give it the signal to shutdown.

---

There's an end-to-end tutorial of these features of Fx at https://uber-go.github.io/fx/get-started/. I recommend going over it when you have a chance.

[debedb]

Yes, sure, but in your example, how do other components refer to the logger or config?

[abhinav]

Yeah, declaring explicit dependencies has the cost of growing parameter lists.
The advantage is that dependencies are explicit and there's no global state. When you write a test for a component, you know exactly what it depends on -- so you know you need a fake logger, a fake database connection, etc.
With the global variant, dependencies aren't obvious, and make testing a lot more difficult. You'll have to initialize everything that something might depend on instead of just the actual dependencies.

FWIW, if the concern is just the list of parameters growing, and not the list of dependencies, Fx also supports the standard parameter object pattern: https://uber-go.github.io/fx/parameter-objects.html. This allows you to declare dependencies of a constructor in a struct. You still have to declare everything explicitly and record it on the Handler/App/implementation, whatever.

[debedb]

Right, so I still have the boilerplate in this case except it's not in the number of constructor arguments, but in duplicating fields, as well as explicit copying from params into my object. What if I were to do something like this:

package utils

import "reflect"

func Construct[P any, T any, PT interface{ *T }](params interface{}) PT {
	p := PT(new(T))
	Construct0(params, p)
	return p
}

func Construct0(params interface{}, retval interface{}) {
	// Check if retval is a pointer
	rv := reflect.ValueOf(retval)
	if rv.Kind() != reflect.Ptr {
		panic("retval is not a pointer")
	}

	// Dereference the pointer to get the underlying value
	rv = rv.Elem()

	// Check if the dereferenced value is a struct
	if rv.Kind() != reflect.Struct {
		panic("retval is not a pointer to a struct")
	}

	// Now, get the value of params
	rp := reflect.ValueOf(params)
	if rp.Kind() != reflect.Struct {
		panic("params is not a struct")
	}

	// Iterate over the fields of params and copy to retval
	for i := 0; i < rp.NumField(); i++ {
		name := rp.Type().Field(i).Name
		field, ok := rv.Type().FieldByName(name)
		if ok && field.Type == rp.Field(i).Type() {
			rv.FieldByName(name).Set(rp.Field(i))
		}
	}

}

And then I could do:

package dependencies

import (
	"example.com/fxtest/utils"
	"go.uber.org/fx"
)

type Foo *string

type Bar *string

type Baz *string

type DependenciesType struct {
	Foo Foo
	Bar Bar
	Baz Baz
}

type DependenciesParams struct {
	fx.In

	Foo Foo
	Bar Bar
	Baz Baz
}

func NewFoo() Foo {
	s := "foo"
	return &s
}

func NewBar() Bar {
	s := "bar"
	return &s
}

func NewBaz() Baz {
	s := "foo"
	return &s
}

func NewDependencies(p DependenciesParams) *DependenciesType {
	retval := utils.Construct[DependenciesParams, DependenciesType](p)
	return retval
}

var DependenciesModule = fx.Module("dependencies",
	fx.Provide(NewFoo),
	fx.Provide(NewBar),
	fx.Provide(NewBaz),

	fx.Provide(NewDependencies),
)

This works; I don't have to do the processing on parameters in the constructor by hand.

But one more annoyance: this still requires me to add both sets of fields in both DependenciesType and DependenciesParams. If I try to avoid it by doing something like:

package dependencies

import (
	"example.com/fxtest/utils"
	"go.uber.org/fx"
)

type Foo *string

type Bar *string

type Baz *string

type DepFields struct {
	Foo Foo
	Bar Bar
	Baz Baz
}

type DependenciesType struct {
	DepFields
}

type DependenciesParams struct {
	fx.In

	DepFields
}

func NewFoo() Foo {
	s := "foo"
	return &s
}

func NewBar() Bar {
	s := "bar"
	return &s
}

func NewBaz() Baz {
	s := "foo"
	return &s
}

func NewDependencies(p DependenciesParams) *DependenciesType {
	retval := utils.Construct[DependenciesParams, DependenciesType](p)
	return retval
}

var DependenciesModule = fx.Module("dependencies",
	fx.Provide(NewFoo),
	fx.Provide(NewBar),
	fx.Provide(NewBaz),

	fx.Provide(NewDependencies),
)

I'll get

missing type:
	- dependencies.DepFields (did you mean to Provide it?)

And if I try to work around it by adding a provider for it:

var DependenciesModule = fx.Module("dependencies",
	fx.Provide(NewFoo),
	fx.Provide(NewBar),
	fx.Provide(NewBaz),
	// This is so we can reuse the fields from DepFields struct in both parameter object
	// (DependenciesParams) and return object (DependenciesType).
	fx.Provide(func() DepFields {
		return DepFields{}
	}),
	fx.Provide(NewDependencies),
)

the constructors of New{Foo,Bar,Baz} don't get called anymore.

Any thoughts? Seems like should be doable?

P.S. Seems like #1110 is somewhat related but not quite).

[abhinav]

I'll let others chime in on this for Fx's position, but here are my thoughts:

I do not consider tracking dependencies for a component explicitly (whether as parameters or fx.In fields) as too much boilerplate. It results in obvious-enough code that's usable even without Fx.

I don't think a singular dependencies object is in the spirit of the problem that Fx is trying to solve. If all dependencies for all components are in one struct, then there's nothing explicit -- you don't know, when instantiating Foo, which of the 50 fields of Dependencies it actually needs.

---

There was an issue somewhere in Fx or Dig for supporting objects that act like fx.In, but also get provided to the container that would theoretically help reduce boilerplate of tracking things in the params and the struct, e.g.

type Handler struct {
  fx.Something // Naming TBD

  Logger *zap.Logger
}

// Given that, the following:

fx.SomethingElse(&Handler{}) // Naming TBD

// Would be equivalent to something like:

fx.Provide(func(p struct {
  fx.In

  Logger *zap.Logger
}) *Handler {
  return &Handler{Logger: p.Logger}
})

I don't know where that issue is, though.

[debedb]

I think the question is also asked in uber-go/dig#338 -- but here while the params are not declared, the Logger fields are still showing up in both Handler and the param struct. I just wanted to collapse those.

[abhinav]

Yeah, I agree. There is a rough idea for a desirable feature sketched-out across a few issues like that one.
It was referred to as "auto-injected" objects in some discussions in the past.
The high-level idea is:

• Objects declare dependencies as fields like with fx.In/dig.In.
• These objects also implement the actual behaviors. So they get provided to the container for others to consume.
• They can have hooks like a Start method to plug into fx.Lifecycle

The exact API hasn't yet been designed.