<p>Performance? Doubtful there is a significant difference, compared to the cost of, say, a database query. It all boils down to accessing arrays, and the number of function calls or string manipulations that it takes to get there is probably not worth worrying about.</p>

<p>The way I see it is that <code>ENV</code> vars are for configuration, and <code>aliases</code> are for convenience / maintainability / legibility of your application's code.</p>

<p>Your example approaches a good explanation for that separation. If you wanted an Environment variable to determine something like an asset volume base URL, I'd recommend this implementation:</p>

<p>1) Create your environment key and value.</p>

<pre><code>MY_ENV_VAR="/some/local/path/or/url"
</code></pre>

<p>2) Create an alias, like <code>@interfaceAssetsBaseUrl</code> that consumes the ENV var:</p>

<pre class="lang-php prettyprint-override"><code>&lt;?php return [
  // Maybe a multi-env config?
  // ...
  'aliases' =&gt; [
    '@interfaceAssetsBaseUrl' =&gt; getenv('INTERFACE_ASSETS_BASE_URL')
  ],
  // ...
];
</code></pre>

<p>3) Use the alias in your volume configuration via the CP's auto-complete feature, i.e. <code>@interfaceAssetsBaseUrl/icons</code></p>

<p> I recommend this, mostly because of the nature of Alias parsing vs. manual string concatenation—the <code>alias</code> function is designed to be used as a substitution, and for the substitution to happen properly, irrespective of configuration. Say your ENV key changes, or you want to override it for a particular environment, or (like me) you forget to populate a variable in a new environment? This strikes me as something you shouldn't have to sweat in the template, but rather let the system take care of when it boots up.</p>

<p>There's an additional benefit of relying on aliases as early as possible, which is recursive evaluation. Here's a config snippet from a real project, which is used to defined a number of (local) asset volumes:</p>

<pre class="lang-php prettyprint-override"><code>'aliases' =&gt; [
  '@shared' =&gt; getenv('SHARED_PATH'),
  '@private' =&gt; '@shared/private',
  '@fonts' =&gt; '@private/fonts'
],
</code></pre>

<p>(This app uses an atomic deployment strategy, so the path to those files changes regularly, but <code>SHARED_PATH</code> is a reliable symlink.)</p>

CC BY-SA 4.0
2019-09-21T08:27:16.820Z
Thanks so much! I wasn't expecting such a detailed answer! 
Jamie Wade
CC BY-SA 4.0
2019-09-20T19:46:32.200Z
2019-09-20T19:46:32.200Z
August Miller
<p>As part of a refactor on our code base, we have been looking into our use of Yii 2's aliases and PHP's getenv function. Here's a code example:</p>

<p><strong>Alias</strong></p>

<pre><code>&lt;link rel="icon" sizes="96x96" type="image/png" href="{{ alias("@interfaceAssetsBaseUrl/img/icons/favicon-96x96.png") }}" /&gt;
</code></pre>

<p><strong>getenv</strong></p>

<pre><code>&lt;link rel="icon" sizes="96x96" type="image/png" href="{{ getenv('INTERFACE_ASSETS_BASE_URL') ~ 'img/icons/favicon-96x96.png' }}"/&gt;
</code></pre>

<p>For context, Interface Assets Base URL is set according to your environment; if you're on Dev it will point to your local files. If you're in Staging or Production it'll point to Amazon S3.</p>

<p>My question:</p>

<p>Is there any benefits in terms or performance in using either one of these methods? Does Craft cache one of these, for example?</p>

<environmentvariables><environments><alias>
Are there any benefits to using Yii's Aliases vs getenv?
# Are there any benefits to using Yii's Aliases vs getenv?

(Asked by: username_0 on 2019-09-20)

As part of a refactor on our code base, we have been looking into our use of Yii 2's aliases and PHP's getenv function. Here's a code example:
Alias


getenv


For context, Interface Assets Base URL is set according to your environment; if you're on Dev it will point to your local files. If you're in Staging or Production it'll point to Amazon S3.
My question:
Is there any benefits in terms or performance in using either one of these methods? Does Craft cache one of these, for example?

**Tags:** environmentvariables, environments, alias


---

## 1 answers

### Answer by username_1 on 2019-09-20. Score: 2 | Accepted answer

Performance? Doubtful there is a significant difference, compared to the cost of, say, a database query. It all boils down to accessing arrays, and the number of function calls or string manipulations that it takes to get there is probably not worth worrying about.
The way I see it is that ENV vars are for configuration, and aliases are for convenience / maintainability / legibility of your application's code.
Your example approaches a good explanation for that separation. If you wanted an Environment variable to determine something like an asset volume base URL, I'd recommend this implementation:
1) Create your environment key and value.
MY_ENV_VAR="/some/local/path/or/url"

2) Create an alias, like @interfaceAssetsBaseUrl that consumes the ENV var:
 [
    '@interfaceAssetsBaseUrl' => getenv('INTERFACE_ASSETS_BASE_URL')
  ],
  // ...
];

3) Use the alias in your volume configuration via the CP's auto-complete feature, i.e. @interfaceAssetsBaseUrl/icons
 I recommend this, mostly because of the nature of Alias parsing vs. manual string concatenation—the alias function is designed to be used as a substitution, and for the substitution to happen properly, irrespective of configuration. Say your ENV key changes, or you want to override it for a particular environment, or (like me) you forget to populate a variable in a new environment? This strikes me as something you shouldn't have to sweat in the template, but rather let the system take care of when it boots up.
There's an additional benefit of relying on aliases as early as possible, which is recursive evaluation. Here's a config snippet from a real project, which is used to defined a number of (local) asset volumes:
'aliases' => [
  '@shared' => getenv('SHARED_PATH'),
  '@private' => '@shared/private',
  '@fonts' => '@private/fonts'
],

(This app uses an atomic deployment strategy, so the path to those files changes regularly, but SHARED_PATH is a reliable symlink.)

> **Comments:**
> **username_0**: Thanks so much! I wasn't expecting such a detailed answer!   

---

