Why Service interface and qualifier has one-to-one relationship

[eutkin]

The interface is converted to a qualifier and back. Qualifier + id nodes is a unique service key in the cluster. In my opinion, it contradicts the nature of interfaces in that we cannot have multiple implementations in one node. Why can we have multiple implementations of an interface within a cluster, but not within a node?

For example, for versioning, we have to create a new interface every time.

Maybe we should consider not only the interface metadata, but also the some metadata of the implementation?

[ronenhamias]

you can have only one interface in one node. i maybe i didn't understand. but service interface is just a definition so maybe more details or example to showcase the point will help to understand. in service definition there is not id.

we do map the implements of a service to their ids but this is done in runtime to route calls to instances in the cluster.

[eutkin]

you can have only one interface in one node. i maybe i didn't understand. but service interface is just a definition so maybe more details or example to showcase the point will help to understand.

My question is why ? Is this constraint necessary?

[ronenhamias]

since interface is a static defintion of a service and the interface is the service itself (not the component that implements it) qulifiers are not an adresss its just the name of the service maybe better to discuss a practical uscase that cannot be done or there is no answer for

[eutkin]

Globally, I don't like this moment here. Scalecube has some constraints, for example:

• one interface, one implementation on one node;
• one argument in the interface method.
• if you are using discovery, you should specify address service discovery in seed members, not address nodes

and so on. Yes, these restrictions are reasonable, logical. But these restrictions are more on words, even in the documentation I do not remember that they were described. And it turns out that the user must create an interface, but he must know that there can only be one implementation.

I think that the API, the essence of the language, should restrict the user from doing things that he shouldn't. That is "idiot proof".

Now I see restrictions as a set of gentlemanly rules. Maybe I'm wrong?

[ronenhamias]

i guess that developers that needs distributed low-latency, reactive-microservices dont expect "idot proff" solution.