We are always in a rush and wanting to develop as quickly as possible, and we often end up adopting old habits and building old software. An item that we can improve a lot is this little thing calledenvironment, let's understand a little more about this.
First of all, I would like to show here the focus on the concept of configurations for laravel, I will not worry about the remaining standards, such as resources or others like that.
1 - Let's seek knowledge!
A while ago I heard that I couldn't do this ENV pass within my crazy codes, I was like; wow
So the purpose is to understand the reasons, because that way, we can make better decisions as engineers.
1.1 - Correct way or a point of view?
So come on little future master, let's put a value in an environment variable so we can play around, so let's call it:
Let's go to the first point, great decision in having placed this configuration as an environment variable, this way you make everything easier to manage different environments (Production, approval, If you have one? ) and much safer, because this value will not be exposed when you perform that naughtygit pushon your repository (git/bitbucket), can you imagine your water secret being leaked on the internet, how sad.
And to retrieve this value in Laravel we can use theenv()method or also use another package such as Support from Illuminate (reminds me of minions, I don't know why?)
env: Laravel Helper (That usesEnv::get)
Env::get: Env class from the Support Illuminate package
Wow, it's ready, so why keep inventing fashion? The truth is that this is not a good idea, I will explain why soon, stay with me.
For the different solution, we can mention the configuration files that will retrieve the value of theenvironmentcreated, so the configuration file is centralized and come on, seriously! much better for reading a code.
In this specific situation you can already use the existing config file, calledservices.php, but nothing prevents you from creating a file for your specific context.
In the pathconfig/services.php
And so we will call it in the code as follows:
2 - Cool, but why should I use configs to retrieve variables and not just fetch them directly?
I'll try to show you some reasons:
2.1 - Increased performance and better IO utilization
Think about the following situation, do you have files in production that will be accessed all the time, carrying out considerable IO, which will increase machine resources and depending on the situation, system slowdowns? (And believe me, until you actually find the problem, you will go through things that will question all your knowledge)
When we talk about the production environment, it is recommended that you cache your beautiful configuration files, with Laravel you can use artisan
php artisan config:cache
This beautiful command takes all the configuration files and their respective values and compiles them into a single php file, which increases performance. This is due to the fact that the IO numbers are reduced to 1
Curiosity:When you use this command, env() starts to returnNULLbecause it disables this function. So if from"Neida"aenv()yours stopped working, that's it.
Env()Perform IO operation and they are expensive and slow.
It is best to do this operation once at the beginning of the application rather than having to perform the operation every time you need an env.
2.2 - 가능한 최선의 방법으로 조직 및 표준화
모든 설정을 원하는 대로 쉽게 유지할 수 있습니다. 원하는 개 이름을 입력하고, 폴더를 만들고 모든 배열을 원하는 대로 구성하면 구조가 더 깔끔해집니다(적당히 사용해주세요)
예:
이 키를 보세요:
이제 이 키를 보세요:
제 소견으로는 1번째가 훨씬 나은 것 같아요
게다가 유사한 구성을 코드에 "무작위로" 배치할 필요 없이 올바른 중앙 집중식 위치에 가질 수 있으며, 애플리케이션에 완전히 적합한 배열을 구성한다는 아이디어가 정말 마음에 듭니다.
새 개발자를 위한 지침은 새 구성을 만드는 위치와 방법을 알려줄 수 있기 때문에 훨씬 간단합니다.
단순하게 유지하고 차이를 만드세요!
지금까지 모든 것에 감사드립니다.
출처:
Laravel 11 구성 문서
The above is the detailed content of Hours is an environment variable, I will use ENV. Calm down, calm down, let me tell you something first. For more information, please follow other related articles on the PHP Chinese website!