How can one component talk to another one directly? about weaver HOT 12 CLOSED

I agree it's subtle. I was thinking of adding a section to the step-by-step tutorial to explain this. I think we could also improve the go docs.

from weaver.

Hi @preslavrachev,

There should be very little restriction on which components can talk to other components and how. Could you elaborate a bit more on the issue you're seeing?

weaver.Init returns a "root" weaver.Instance, which can be used via weaver.Get[Foo] to establish a connection to an arbitrary component Foo. The type that implements Foo also embeds weaver.Implements, which provides its own weaver.Instance, which allows Foo to establish a connection to an arbitrary component Bar via weaver.Get[Bar]. And so on.

Really, weaver.Instance is just a way for us to identify which components are calling other components. (It also helps ensure that weaver.Get is guaranteed to be called after weaver.Init.) In general, weaver.Get should be treated as a global method that can be called from anywhere anytime, as long as you have a weaver.Instance around.

Hope this helps. If what I said isn't true, please share a code snippet. It's possible that our API needs to be improved to make this clearer.

from weaver.

``@spetrovic77 Thanks for the thorough explanation!

The type that implements Foo also embeds weaver.Implements, which provides its own weaver.Instance, which allows Foo to establish a connection to an arbitrary component Bar via weaver.Get[Bar]. And so on.

I was totally unaware that by embedding weaver.Implements, a component implicitly turns into a weaver.Instance too:

So, this is working now!

// A component.
type A interface {
	Foo(context.Context, string) (string, error)
}

// Implementation of the A component.
type a struct {
	weaver. Implements[A]
	b B
}

func (a *a) Init(_ context.Context) {
	b, err  := weaver. Get[B](a)
	if err != nil {
           // handle the error
        }
       a.b = b
}

I suggest two things:

A) Add a section to the documentation that demonstrates inter-component communication (I can send a PR if you tell me where).
B) update Init (or come up with a new lifecycle method) so that it returns a possible error.

from weaver.

Yeah, you are right, the fact that weaver.Implements makes the implementation a weaver.Instance is pretty subtle. WDYT @mwhittaker ?

from weaver.

Yeah, it doesn't help that our tutorial examples are one-level, i.e., main() Gets a component which in turn doesn't Get another. Maybe we can use a slightly more complex example?

from weaver.

Does this example https://github.com/ServiceWeaver/weaver/tree/main/examples/onlineboutique satisfies the above request?

@preslavrachev If you take a look here, is that what you're after? https://github.com/ServiceWeaver/weaver/blob/main/examples/onlineboutique/checkoutservice/service.go

from weaver.

Yeah, we have a lot of code examples, but the tutorial should also talk about this since most folks will run into it.

from weaver.

@amrnt Yes, precisely.

@spetrovic77 @mwhittaker I agree with an addition to the docs. As much as the Go community keeps being divided on the topic of dependency injection, that's precisely what it is, and in the case of large, distributed applications, it is very useful.

What I am a little bit concerned about is that the way of "pulling" dependencies inside a component is very implicit. It is not only against the Go philosophy, but has a few general drawbacks like, how do we test components in isolation? With a regular NewXXX function, I can explicitly pass arguments that satisfy those dependencies. Now, I am only able to set the entire chain up with weavertest.Init, but that's about it. For isolated component testing, would you recommend adding an explicit constructor function that gets used for testing?

P.S. Forget my previous comment about Init needing to return an error. It already does - I simply had forgotten to duble-check the spec :) This might be a problem, because if someone implements Init incorrectly, it won't be called and this might cause a bunch of runtime issues. I'd rather have it checked at generation time (I'll open a separate issue for that).

from weaver.

What I am a little bit concerned about is that the way of "pulling" dependencies inside a component is very implicit. It is not only against the Go philosophy, but has a few general drawbacks like, how do we test components in isolation? With a regular NewXXX function, I can explicitly pass arguments that satisfy those dependencies. Now, I am only able to set the entire chain up with weavertest.Init, but that's about it. For isolated component testing, would you recommend adding an explicit constructor function that gets used for testing?

@preslavrachev Can you file a new issue with more details on which type of testing you'd like to do? In theory, if your component implementation doesn't use any Service Weaver APIs, you should be able to create an empty instance of the implementation and call methods on it.

If your component does call Service Weaver APIs, you can create a simple test that calls weavertest.Init and then Gets your component.

Is your concern testing component A, which internally calls component B's methods? And you would rather not instantiate B, but perhaps mock while testing?

In any case, please file a new issue and we'll take a look.

from weaver.

Hello there,
I'm trying to achieve to implement dependency injection with service weaver.
I tried this piece of code weaver.Get[Foo] but I'm getting a error during compilation.

undefined: weaver.get

This error happens for version v0.13.0 and v0.16.0.

What versions did you use for that?

from weaver.

@Markbnak I think the SW API has changed a little since the last comment here. I am not sure if this will help you, but I wrote an article on dependency injection using SW acouple of months ago: https://preslav.me/2023/05/12/golang-dependency-injection-in-google-service-weaver/

Check it out, and I'd be happy to issue an updated version if you find something that does not work.

from weaver.

@preslavrachev thanks for sharing your blogpost

from weaver.