چرا کانفیگ ها رو با dotenv مدیریت کنیم؟

سلام و احترام

نکته همینجاست، نرم افزار نباید ارتباط مستقیم با env داشته باشه (البته اگه کوچیکه زیاد موردی نیست)، ما یه فایل config.php ایجاد میکنیم که تمامی کانفیگ های لازم رو از env میخونه و ما هر جا توی نرم افزارمون خواستیم از توی config صدا میزنیم و استفاده میکنیم

حالا چرا نباید ارتباط مستقیم با env داشت؟

شاید ما در بعضی از جاها بخواهیم مقدار پیش فرض یا چند گزینه ای برای یک کانفیگ خاص قرار بدیم  و شاید حتی یه کانفیگ تنظیمات مربوط به خودش رو داشته باشه که نشه همه رو توی env قرار داد، به این مورد توجه کنید

این کانفیگی هست که در env برای سرویس queue گذاشته شده (برای لاراوله)

QUEUE_CONNECTION=redis

این فایل کانفیگ queue در لاراول هستش (توی پوشه config) و ببینید که در فایل کانفیگ خودش ما دستمون بازه یه سری تنظیمات انجام بدیم و پیش فرض ها رو تغییر بدیم (نوع درایور queue رو هم میشه از env تغییر داد که در مثال بالا دیدیم)

<?php

return [

    /*
    |--------------------------------------------------------------------------
    | Default Queue Connection Name
    |--------------------------------------------------------------------------
    |
    | Laravel's queue API supports an assortment of back-ends via a single
    | API, giving you convenient access to each back-end using the same
    | syntax for every one. Here you may define a default connection.
    |
    */

    'default' => env('QUEUE_CONNECTION', 'sync'),

    /*
    |--------------------------------------------------------------------------
    | Queue Connections
    |--------------------------------------------------------------------------
    |
    | Here you may configure the connection information for each server that
    | is used by your application. A default configuration has been added
    | for each back-end shipped with Laravel. You are free to add more.
    |
    | Drivers: "sync", "database", "beanstalkd", "sqs", "redis", "null"
    |
    */

    'connections' => [

        'sync' => [
            'driver' => 'sync',
        ],

        'database' => [
            'driver' => 'database',
            'table' => 'jobs',
            'queue' => 'default',
            'retry_after' => 90,
        ],

        'beanstalkd' => [
            'driver' => 'beanstalkd',
            'host' => 'localhost',
            'queue' => 'default',
            'retry_after' => 90,
            'block_for' => 0,
        ],

        'sqs' => [
            'driver' => 'sqs',
            'key' => env('AWS_ACCESS_KEY_ID'),
            'secret' => env('AWS_SECRET_ACCESS_KEY'),
            'prefix' => env('SQS_PREFIX', 'https://sqs.us-east-1.amazonaws.com/your-account-id'),
            'queue' => env('SQS_QUEUE', 'your-queue-name'),
            'suffix' => env('SQS_SUFFIX'),
            'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
        ],

        'redis' => [
            'driver' => 'redis',
            'connection' => 'default',
            'queue' => env('REDIS_QUEUE', 'default'),
            'retry_after' => 90,
            'block_for' => null,
        ],

    ],

    /*
    |--------------------------------------------------------------------------
    | Failed Queue Jobs
    |--------------------------------------------------------------------------
    |
    | These options configure the behavior of failed queue job logging so you
    | can control which database and table are used to store the jobs that
    | have failed. You may change them to any database / table you wish.
    |
    */

    'failed' => [
        'driver' => env('QUEUE_FAILED_DRIVER', 'database-uuids'),
        'database' => env('DB_CONNECTION', 'mysql'),
        'table' => 'failed_jobs',
    ],

];

----------------------

حالا ما اومدیم env رو هم gitignore گذاشتیم ولی چرا؟

توی env ما اطلاعات حساس نرم افزارمون رو داریم و نباید دست کسی بدیم تا ازش خبر دار باشه چون در نهایت کسی که ضربه میخوره ماییم به خاطر همینه که env اگه در معرض دید باشه برای ما خطرناکه سر همین مورد هم معمولا env.example رو به جا به جا میکنن که توش اطلاعات خام هستش و اهمیتی نداره