modify objects already provided in the graph

[srikrsna]

First of all, thank you for this excellent library. It is idiomatic and helped us a lot in deploying our services with ease.

One thing that will be nice to have (and I would like to contribute to) is to have a way to modify objects that are already provided in the graph. As we deployed our services such patterns were required more on more.

Example:

We wanted to add Open Census metrics and trace to our application. This can be done by wrapping the http handler in Open Census's http handler. Currently we modify the handler provider/invoker function to check if open census is enabled and wrap the http handler to return an Open Census enable http handler. If we had a way to modify provided objects especially interfaces i.e. provide a wrapped implementation things like tracing caching auth can be separated into their own layer.

This can be implemented without any breaking changes. It will require a new API, something like, fx.Modify(...) which will take inputs from providers and return providers that were already in the graph. Modifiers will only be applied if types returned by them have been requested by invokers.

What do you think of this?

[glibsm]

Linking in the related discussions: #531 #649

[srikrsna]

Option C of #531 is more or less what I am proposing and would elegantly solve my problem. One concern seems to be that the order in which such decorators will be applied. Can't they be like Invoke, i.e. in the order provided?

[srikrsna]

Any plans to implement this?

[abhinav]

Hey, we haven't had a chance to fully evaluate how this affects the rest of
Fx. Decorators can likely be applied in-order but we need to evaluate how they
interact with other existing and upcoming features of Fx like named values,
value groups, and fx.Annotated (#610).

We may have some time to look into this in a few weeks.

[srikrsna]

I am unable to understand how named values and value groups differ from the graph's perspective they are like any other value, aren't they? Could you please explain.

And I suppose this should be supported by dig first. Should I open an issue there?

[abhinav]

Yes, happy to clarify! From the point of view of fx.Decorate, named values
and value groups open up some questions:

• When I provide a decorator for type F, does that apply to all instances of
  F or only the unnamed ones?

      fx.Provide(
          fx.Annotated{Name: "foo", Target: func() F { ... }},
      ),
      fx.Decorate(
          func(F) F { ... },
      ),
  

  If it applies only to unnamed ones, that means decorators have to explicitly
  specify which named value they apply to.

• Similarly, if F is actually being fed into a value group, does the
  decorator for F apply to all Fs provided to that group?

      fx.Provide(
          fx.Annotated{Group: "foo", Target: producer1},
          fx.Annotated{Group: "foo", Target: producer2},
          fx.Annotated{Group: "foo", Target: producer3},
      ),
      fx.Decorate(
          func(F) F { ... },
      ),
  

• Going further, does a decorator for []F apply only to explicitly provided
  []Fs or also to the value group-version consumed by the fx.In?

      type Param struct {
          fx.In
          
          Fs []F `group:"foo"`
      }
      
      fx.New(
          fx.Provide(func(p Param) Bar { ... }),
          fx.Decorate([]F) []F { ... },
      )
  

I think we would have to figure out a good plan for the above and any other
related questions that come up before this can be implemented.

---

Yes, this would need to be implemented in dig first. We don't need to
necessarily open the issue there since the two repos are pretty coupled
together anyway. (We've been considering merging dig into fx.)

[srikrsna]

So I was thinking something more like this,

Since the purpose of decorators is to modify values already available and instantiated in the graph, named values, value groups (the actual slice), and normal values all count as a unique value available in the graph. Let me elaborate with examples and try to lay out rules to better explain what I am proposing.

• Decorators are useful for modifying input values for invokers and linked providers.
• Decision that a decorator is to be applied or not is decided by its output type.
• Its a lot like provide but unlike provide it can also optionally (although most likely) accept its own output types. Example:

fx.Provide(
    func (...) X { 
    // ...
    },
    func (...) F {
     // ...
    },
),
fx.Decorator(
   func(x X, f F) F { ... },
)

• Decorator functions can accept fx.In and also return fx.Out types.
• They can accept Lifecycle type.
• In case of a value group the value group should be requested and be returned as a slice. i.e.

   fx.Provide(
        fx.Annotated{Group: "foo", Target: producer1},
        fx.Annotated{Group: "foo", Target: producer2},
        fx.Annotated{Group: "foo", Target: producer3},
    ),
    fx.Decorate(
        func(in struct {
         fx.In
         Fs []F `group:"foo"` 
        }) struct{
          fx.Out
          Fs []F `group:"foo"`
        } { ... },
    ),

This is OK because currently fx does not make any guarantee in terms of order of the values so modifying them all at once should not be a problem. The first point also supports this argument as we are only trying to modify the inputs, value groups are resolved to slices when provided and hence should be modified in that form.

What do you think of this?

[abhinav]

That sounds like a good plan. Decorators will reference values/named values
explicitly, and value groups can modify all values in a loop because of the
unspecified-ordering guarantee. Modifying a single value of a value group
isn't supported because at that point, you should just modify the
corresponding constructor directly.

The implementation of Decorate will almost definitely need a check which
verifies that you're not producing anything you didn't consume (so you can't
add new provides from a decorator), and it'll have a special-cased behavior
for value groups where producing a slice []Foo for a value group fills the
same value group instead of [][]Foo. Oh, and this also makes it possible to
"expand" a value group by returning more items in the fx.Out version than the
number received in the fx.In of a decorator.

[srikrsna]

@abhinav shall I start implementing what we just discussed?

[glibsm]

Oh, and this also makes it possible to "expand" a value group by returning more items in the fx.Out version.

This worries me. We can technically runtime safeguard against this, but not sure if that's something we should stick our hand in.

[abhinav]

@srikrsna We're having some active discussion about fx.Decorate ordering. I
would hold off on implementing this until that's resolved.

@akshayjshah @glibsm Let's discuss ordering for the case where multiple
fx.Decorates are provided.

Also, @rhang-uber, do you think we would change the visualization in Dig for
something like this or keep it as-is?

[akshayjshah]

@srikrsna After a bit more than a year of Fx use, our internal ecosystem has a pretty deep graph of dependencies, across multiple teams (and multiple offices around the world). Many Fx modules are written by engineers who don't have the time or inclination to read all the Fx docs. Today, this works pretty well because fx.Provide is order-independent, and most modules only provide types. It's pretty hard to mess up. I'm worried that decorators will introduce something similar to aspect-oriented programming, where we enable spooky action at a distance. If that action is also order-dependent, we'll end up with a more brittle module system that's harder for users to debug.

On the other hand, this is a really valuable feature - we've discussed it multiple times now.

Before you put a ton of effort into implementing this, let me think on this for a bit.

[glibsm]

Just thinking out loud here, what about fx.Replace?

Instead of dealing with the instantiated objects to modify their state, we would allow to replace the constructor that provided the type? Instead of massively complicating the dig/fx internals it would put the onus on library authors to make sure their modules use public constructors (as per our guidelines).

fx.Provide(func() A  { ... })
fx.Provide(func() B { ... })
fx.Replace(func () B { .. some other B function }) // errors out if B doesn't exist or signatures don't match
fx.Invoke(func (a A, b B) { ... })

I'm thinking that dealing purely with constructor functions manipulation, rather than dropping down to instantiated objects may be a better road to take and should still allow the usages that fx.Decorate is meant to solve.

Dig could queue up all replaces and run them in between Provide and Invoke.

[srikrsna]

fx.Replace in my humble opinion will result in more duplication. I will try an explain a real world situation that I will face,

We use gRPC for developing all our services. And almost all services are written in Go. I developed a simple authorisation library (internal) that generates gRPC server implementation that check if the user has the right to access a specific rpc and call the underlying server implementation.

type RightsEchoServer struct {
     pb.EchoServer // interface
     ....
}

func NewRightsEchoServer(s pb.EchoServer, ...) pb.EchoServer {
     return &RightsEchoServer{s, ...}
}

func (s *RightsEchoServer) Echo(ctx context.Context, req pb.EchoRequest) (*pb.EchoResponse, error) {
     var hasRight bool
      // Check Rights ...
     if !hasRight {
            return nil, status.Error(codes.Unauthorized, ...)
     }

      return s.EchoServer.Echo(ctx, req)
}

Now in case of proposed fx.Decorate, the code would look like this

     fx.Provide(NewEchoServer),
     fx.Decorate(NewRightsEchoServer),

In case of fx.Replace this would be

     fx.Provide(NewEchoServer),
     fx.Replace(func (d D, ...) (pb.EchoServer, error) {
            s, err := NewEchoServer(d)
            if err != nil {
                  return 
            }
            return NewRightsServer(s, ...), nil
     }),

And in case of multiple such decorators the code would only increase. But in case of ordered decorators it would be just adding them to the list.