What is the reason behind six params files?

Yii 2.0 General Discussions
1

In the beginning of main.php configuration file I have noticed the following code:

$params = array_merge(
    require __DIR__ . '/../../common/config/params.php',
    require __DIR__ . '/../../common/config/params-local.php',
    require __DIR__ . '/params.php',
    require __DIR__ . '/params-local.php'
);

This has made me really suspicious. Why do we introduce four different params files, only to merge them all together in the first step?\

Things that bothers me the most:

  1. If we assume that in App Advanced Theme the very same code exists for frontend app, this gives us six separate files for storing application parameters.

  2. Exactly the same situation is for actual configuration, where we have main.php and main-local.php files stored for backend, frontend and common applications / folders.

  3. If we assume that params actually are also piece of configuration, we finally land with the picture that a Yii 2 App Advanced Theme uses TWELVE configuration files.

Can someone take the advantage and explain me the logic behind this? I mean – from business perspective, meaning what should I store in which file (and why twelve files)?

I started describing this to my customer (in README.md) file, at which step of application deployment he should configure what and in which file. And drowned completely.

He started to read what I have already managed to write and rejected the whole thing after a 15 minutes, claiming that having twelve configuration files is a pure madness. I can’t find arguments to counter-strike his thinking! :[

2

Yii 1.1 ideas of how to organize apps were taken into account:

  • common is applied to both frontend and backend.
  • *-local is excluded from git and is meant to override settings in a local environment.

Yii isn’t focing you to have all these configs. You can remove some if needed and, for exampe, use environment variables instead.

3

It is a good design and it is very useful, especially when you work as a part of a team. Just separate concepts:

  1. Config files are defining structure of application, usually components.
  2. Params files are defining variables the components use. They are subject to change, to adjust app behavior without changing its structure.
  3. Each tier has its own configuration which is much easier to maintain and you should have only that tier related config inside.
  4. “-local” files are useful for developers having possibility to set up own local configuration (distinct database, dev components, whatever). Notice that the files are ignored by git so they are distinct for every team member what ensures that there will be no conflicts and you can have the dev environment under your control.
  5. The app structure is based on “layers” where one (or more if you want) is common. This way you set up for example logging component only one time for whole app.

So you can think of configuration (and params in parallel) as the tree like this:

common
├── main  # components used everywhere
│   └── main-local # local overlay for development
├── backend
│   └── main  # common + backend specific config
│       └── main-local # local overlay for development
└── frontend
    └── main  # common + frontend specific config
        └── main-local # local overlay for development

For your customers you should omit all “-local” config and params because they are only yours and should never be visible or deployed to them.

4

Thanks, I know their technical aspects. I was more than interested in business purpose of each. What is nicely explained by Bart below.

Yeah, I know. I was more like trying to get the whole picture. Thanks.

5

Thanks for the detailed explanation on the concpets. Much appreciated.

Yes, but you should always look at the other side. Because out-of-the-box we land with six different params files that in total stores six params. Including three different email addresses. Plus fourth (damn!) username, in mail transport configuration, which is email address as well in most scenarios.

I partially get the idea of having separate adminEmail (in backend) and supportEmail in frontend. But I am completely failing on the idea behind having senderEmail in common. Without any piece of comment in these files, I have to dig through source code to learn when which will be used. And why do I need three of them (if most companies are using no-reply for automatically generated emails)?

These are just my doubts, not questions. And I know that I can get rid of it and change it the way I want. I just want to point it out that out-of-the-box configuration brings little value and much confusion around serving six params files and six configuration files to the developers. But that’s a private opinion.

That’s seems to be totally incorrect. If I won’t deploy these files (params-local.php) to my customer then their application will simply fail. All params out-of-the-box are stored in -local files.

Without deploying these files or without making changes in code, (i.e. moving these params to “main” files and committing them to VCS) any email-related functionality will either fail totally or starts sending emails with empty header etc.

6

For me it is working pretty neat. This way I’m sure I can have my own different configuration for development and be sure that in production it is working with production config. You dont’t have to remember about it, you can deploy new updates without risk of damaging config.

All params out-of-the-box are stored in -local files.

Yes. For me it is obvious as you are never have the app in production ready state out of the box. First it has to run in your local environment and then you know how to prepare production one.

1 Like
7

My question was more like to clarify your logic, because you seems to be contradicting yourself a bit.

First you say that there is no problem that there are twelve config-like files, because client (or member of the deployment team) shouldn’t be aware about those -local ones. I assumed that therefore I should say nothing about these parameters in my client’s instruction or deployment’s guide.

Then you say that it is OK that certain values are stored in -local files, because application must be correctly setup before it is ready to run in production mode. This leads to a conclusion that these -local files must be mentioned in client’s instruction or deployment’s guide.

Which leads us back to the root. My instruction / installation guide must include information that at some point somebody, when deploying an application, is dealing with a number out of twelve configuration-like files. Which seems an overkill as for me.

But this is just my personal opinion. You are for sure true about one thing – everyone is designing their applications their own way, and Yii is flexible enough to let one split application configuration to twelve files or have it “merged” into single one.

8

Maybe we misunderstood each other somewhere. For me “-local” files are exclusively for your local, development purposes. The app developed to the customer must run without “-local” files present at all. They only live in your environment, changing / adding some features for your workflow.

9

OK, so how do you read all those parameters (that in your local environment are set in -local files) in your production deployment?

You have:

return [
    'senderEmail' => 'account@example.com',
    'senderName' => 'My App Name',
    'user.passwordResetTokenExpire' => 3600,
    'user.passwordMinLength' => 8
];

Set (in Yii 2 Advanced Application Theme) in /common/config/params-local.php.

You are not deploying this file to the production. From where your production-mode-running application gets these parameters?

You have them set (and committed to VCS) in /common/config/params.php for the production mode and only override them in /common/config/params-local.php for local environment (assuming that *-local.php files takes precedence over *.php configuration files)?

10

Exactly! That’s the essence.

3 Likes