Handling multiple implementations

[Peter Aba]

Hi,

Sorry if this should be obvious, but after having read the docs, I'm still wondering a bit how to differentiate between two implementations of an interface. Let's say I have two `Reverser` implementation: `reverser` and  `reverser2`. How do I effectively tell ServiceWeaver which one to return when calling `weaver.Get[Reverser](root)`?

It's clearly possible, it's just not clear to me how.

Thanks,
Peter

[mwhittaker]

Hi Peter,

Every component interface should have exactly one component implementation. `weaver generate` will error out if you have two implementations of the same component interface. 

Technically, you can implement a component interface multiple times, but only one can embed `weaver.Implements[T]` for the interface `T`.

Best,

Michael

[Peter Aba]

Hi Michael,

thanks for coming back to me so quickly.

That's actually an interesting limitation. I have to wonder why, though I have to admit that I don't necessarily have a strong use case for having multiple implementation right now. I'm guessing if you wanted to build something like an open source e-commerce platform, you might want to bundle in a few variants for some of the components and let the user choose the implementation based on configuration, but I'm not sure.

Do you see it as something that you'd attempt to fix or are you happy with the design as is?

--
You received this message because you are subscribed to the Google Groups "Service Weaver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serviceweave...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/c9b0b0a3-b27d-43ad-aea7-170d29aed35cn%40googlegroups.com.

[mwhittaker]

> I'm guessing if you wanted to build something like an open source e-commerce platform, you might want to bundle in a few variants for some of the components and let the user choose the implementation based on configuration, but I'm not sure.

Yeah, that's a great example! Very interesting. I guess when writing unit tests, it may also be helpful to swap out a component implementation for a fake or mock implementation. 

> Do you see it as something that you'd attempt to fix or are you happy with the design as is?

We might revisit the API, but I don't think we have any short term plans. If we find a lot of users want this feature though, we ca re-prioritize it!

[Amitabh Ojha]

Hi Peter, I am trying to create a component that will consume Kafka messages for a given topic and group Id. In order to scale I would like to create multiple instances of the component based on factors such as partition count in the Kafka cluster topics. Each instance could be initialised with a specific topic and group Id. While this use case does not require multiple implementations, it does require controlled instantiation of the same component several times with varying startup configurations. Is this possible in the current implementation of service weaver?

[Peter Aba]

Hi Amitabh,

I think I'm not the right person to ask, but it sounds doable to me. :)

Cheers,

Peter

[mwhittaker]

Hi Amitabh, 

Great question. I think you're getting at two things: (1) can you control the number of replicas of a component, and (2) can you instantiate every replica with a different set of configuration. 

For (1), the deployer determines the number of replicas of a component. For example, the `weaver multi` deployer right now always runs two replicas of every component. The GKE deployer scales the number of replicas based on load. The `weaver kube` deployer produces a set of Kubernetes YAML files that you can `kubectl apply -f`. It should be easy to edit the output of the `weaver kube` deployer to specify a specific number of replicas. If you need more advanced control over the number of replicas, I would tweak an existing deployer or write a new one. 

For (2), every replica of a component is instantiated with the configuration you put in the config file. If you need every replica to start with a different topic and group id, I would use an external database or something similar. For example, when a replica of a component starts, it can pop a topic and group id from an external database to use.

Best,

Michael