Exploring Hierarchical Configurations in Applications

[hrstkatomas]

So I was exploring the concept of providing my application with config values using hierarchical containers. It was inspired by the hierarchy of containers Angular has.

Here's the structure I'm considering:

• Platform container
  • Page container
    • Feature container

Each container can specify configuration for different abstraction levels:

• Platform Containers: These can define server-specific or browser-specific configurations.
• Page Containers: These can specify configurations for individual pages, allowing for different requirements between a highly interactive home page and a static "about" page.
• Feature Containers: These can define the configuration for specific features.

Feature needed some platform-specific configuration? Container hierarchy got you covered.
Also, the idea seemed fairly flexible because I could override any configuration at any level if needed.

The named binding seemed like a good idea. I could hide my config values under one key:

container.bind("Config").toConstantValue("https://myAPI.com/").whenTargetNamed("apiUrl");

When I tried it I encountered this issue #954
There are ways around this, but I am unsure I went down the right path.
I guess I violated the "Avoid the injection of data, as opposed to behaviour" principle mentioned in the good practices section of the documentation.

Is there a way to achieve this kind of configuration flexibility while providing an abstraction of the configuration? I would appreciate any suggestions on how to approach this. Thank you!

[notaphplover]

Hey @hrstkatomas, thank you so much for bringing up the discussion. It's sort of late in my timezone so I'll provide a proper answer tomorrow, let me say for now that I do believe there's a way to satisfy your use case with the actual behavior 😃

Edit: Ok, it seems I have more time. In order to keep an structured discussion, I'll start here talking about your use case.

Here's the structure I'm considering:
Platform container

• Page container

  • Feature container
    Each container can specify configuration for different abstraction levels:

• Platform Containers: These can define server-specific or browser-specific configurations.

• Page Containers: These can specify configurations for individual pages, allowing for different requirements between a highly interactive home page and a static "about" page.

• Feature Containers: These can define the configuration for specific features.

I see, at first glance I would probably resolve with ContainerModules since I understand two platforms don't have lot's of common base bindings, but maybe this is a misconception on my side. As an example, backend and frontend configurations probably share some bindings, like endpoint validators and maybe an HTTP client to consume the API, but at first glance it seems way easier to rely on ContainerModules so both frontend and backend container load them after.

I guess I violated the "Avoid the injection of data, as opposed to behaviour" principle mentioned in the good practices section of the documentation.

Yeah, I think it's fine. They are just suggestions. My cup of teawould be having a ConfigurationService which probably can be iterated to fetch env vars or config from any other source, but sometimes keeping things simple is the best way to go.

Is there a way to achieve this kind of configuration flexibility while providing an abstraction of the configuration? I would appreciate any suggestions on how to approach this. Thank you!

Sure, First I would like to know the reason to not to use ContainerModule instead. Tbh I want to improve this in the future, I want to provide better modules so you can easily accomplish that level of customization without thinking too much.

[hrstkatomas]

I was planning to use ContainerModules to load data into the hierarchical container I described as needed. It just felt like an implementation detail to mention that.

However, I'm not sure if I'm interpreting your message correctly. Are you suggesting that I avoid using hierarchical containers in favor of using only ContainerModules? 🤔 I believe that these two features can be used together, rather than being mutually exclusive. Or maybye I just have my mental model wrong.

[notaphplover]

Now, regarding #954:

When I tried it I encountered this issue #954
There are ways around this, but I am unsure I went down the right path.

Yeah, I get your use case and makes sense for this use case. Unfortunatelly, inversify is so flexible that changing the behavior would lead to some weird behaviors in my humble opinnion.

The current beahvior

• Given parent container p
• Given child container c
• Given service id s

c.get finds registered bindings at c. If no bindings are found, p bindings are used instead.

You're probably wondering what does "if no bindings are found" mean.

const parentContainer = new Container();
parentContainer.bind("SHARED").toConstantValue("V1").whenTargetNamed("S1");

const childrenContainer = parentContainer.createChild();
childrenContainer.bind("SHARED").toConstantValue("V2").whenTargetNamed("S2");

// An error is thrown
childrenContainer.getNamed("SHARED", "S1")

Well, childrenContainer has registered bindings for the "SHARED" services. Are they valid in the scope of childrenContainer.getNamed("SHARED", "S1"). No, they are not, but that's not relevant in the current behavior.

Should we change this behavior?

I don't think so. A child container is supposed to override service bindings. Two possible behaviors come to my mind

Provide fine grained overrides

I am aware parentContainer.bind("SHARED").toConstantValue("V1").whenTargetNamed("S1"); looks like there's sort of a granularity and might be able to define fine grained overrides. I don't think that way. Keep in mind whenTargetNamed just adds a constraint. Bindings can be bound under custom constraits outside any concept of granularity. As an example, a single binding constraint can check both the name of the current service being planned and tags from the parent service being planned.

A child container could always use both parent and their own bindings

I believe this would be really confusing given the current behavior and there would be no way to replace parent bindings by child bindings.

Of course, I'm open to talk about this and any other proposal.

[hrstkatomas]

I’m sorry to disappoint you, but I don’t have a strong preference for which solution we should choose as a community; either option sound fine to me. 🙂

My expectation that this would work was based on the documentation I referred to in the issue mentioned.

[notaphplover]

Hey @hrstkatomas, I'm not dissappointed at all 😃 .

My expectation that this would work was based on the documentation I referred to in the issue mentioned.

As I tried to explain in my previous answer, the container is working as expected. In the previous example:

const parentContainer = new Container();
parentContainer.bind("SHARED").toConstantValue("V1").whenTargetNamed("S1");

const childContainer = parentContainer.createChild();
childContainer.bind("SHARED").toConstantValue("V2").whenTargetNamed("S2");

// An error is thrown
childContainer.getNamed("SHARED", "S1")

childContainer overrides "SHARED" bindings when "SHARED" bindings are registered, as it should be. That's what docs say. Having said that, they might be sort of ambiguous so I'll update them to clarify this.

either option sound fine to me. 🙂

As said, none of the two solutions that come to my mind are great ones. They might solve your use case but ruin common use cases that are expected to work the way they are working.