[Config] Purpose and Misusage of Component

[chr-hertel]

Hi there,

over the last years I came across multiple occasions where I felt like the config component being misused for application config and I wonder if that's only me, if you feel like this is an issue we should address in the docs of the component or if the best practices address it enough in an indirect manner. Maybe I missed a part in the docs, that already clarify - or I'm simply wrong here.

My understanding:
The config component provides a solution for defining a configuration contract between two parties, e.g. a bundle provider and a bundle consumer.

It is not meant to define an applications configuration, but this is what I sometimes see - developers going an extra mile defining and validating their applications configuration. Do you consider this a bad practice? should we point this out here or is it me?

Thanks already for your feedback!

[fabpot]

Using the Config component for userland configuration is a valid use case even if probably overkill most of the time.
The main use case for the Config component is to be able to validate the configuration, so it makes sense if the config is going to be reused multiple times.

[derrabus]

Hello Christopher,

thank you for raising this topic.

the config component being misused for application config

I'm having trouble with the term "misuse" in that context. You totally can use the config component for application configuration. It's just not how the component is used in new Symfony applications out of the box. And in many scenarios, the Config component might simply be a bad fit for application configuration.

My understanding:
The config component provides a solution for defining a configuration contract between two parties, e.g. a bundle provider and a bundle consumer.

💯

And those two parties could as well be the vendor of an application and the integrator of said application. Imagine you develop an COTS application that your customers can install on their own systems. Whoever conducts the installation (lets call them integrator) has probably no idea what a bundle is or even that your application uses Symfony as an application framework. They simply want to set up your application for themselves or their users.

In this context, it might make sense to establish a well-defined configuration file format (e.g. in YAML or XML), and the config component gives you all the tools you need to validate and process such a configuration. Apart from that, you're pretty much on your own. You will probably need to translate that application configuration into a framework configuration or implement other means of caching because processing configuration is expensive and you don't want to do that e.g. on each request.

What I've outlined here is one of multiple valid solutions to a problem that only a few applications built with Symfony need to solve. The goal of the best practice guide however is to provide very broad and general advice for developing Symfony applications in a somewhat beginner-friendly way. It should be read as, "follow those practices unless you have a good reason not to". The guide is certainly not a one-size-fits-all solution simply because there are just so many different types of applications that you can build with a general-purpose application framework like Symfony.

In that light, I'm very much happy with the current recommendation of using parameters for application configuration. In most applications, you might not even need any application configuration at all. And even if you do, using the Config component might be overkill.

[wouterj]

The Config component is great in validating and merging multiple sources of configuration (and also loading different formats). So the use-case of application configuration is not necessarily "misuse", although it will be overkill for most.

The section you linked is already talking a lot about using parameters for application configuration, but maybe we can be more explicit about it vs the Config component (it's currently focusing on env vars vs container parameters): #20012

[chr-hertel]

Thanks everyone for answering and yes, misuse is maybe too strong of an Assessment, but Overkill in a sense of introducing too much complexity for something that could be solved differently.

Also pointing out that merging feature is a good one - and we also have the use-case of a monolithic system with multiple teams around one central configuration.

Thanks @wouterj for directly acting on it ❤️

Would you agree on main features being:

• Defining a config structure, incl. validation, defaults & docs
• Supporting different config formats
• Merging different files into unified config

Maybe as an addon for the component docs?

[OskarStark]

Would you agree on main features being

Yes 👍

[derrabus]

Would you agree on main features being:

• Defining a config structure, incl. validation, defaults & docs
• Supporting different config formats
• Merging different files into unified config

Sounds about right.

[javiereguiluz]

@chr-hertel I think that #20012 doesn't fully solve your concerns ... so I propose #20044 to better clarify the purpose of the Config component. Thanks.

[chr-hertel]

Would be a great addition to address that topic IMO 👍