🎯 Key points for quick navigation: 00:00 *🚫 Worst Laravel Practices Overview* - Definition of bad practices in Laravel - Introduction to the top 5 worst Laravel practices 01:51 *⏱️ Bad Practice #1: N+1 Query* - N+1 query is a major cause of performance issues in Laravel - Solutions include using Laravel debug tools, proper eager loading, and prevention techniques 03:01 *💾 Bad Practice #2: Loading Unnecessary Data* - Loading full relationships or unnecessary data can lead to performance degradation - It's essential to only load the data that is actually needed 04:12 *🔄 Bad Practice #3: Not Checking Relationships* - Failing to check relationships or objects can result in errors, especially when chaining methods - Best practice is to validate the existence of objects before using them 05:21 *🚨 Bad Practice #4: Inconsistent API Status Code* - Returning JSON responses with incorrect status codes can lead to confusion for frontend developers - Consistency in API status codes, especially for errors, is crucial for clear communication 06:31 *🔒 Bad Practice #5: Trusting User Data Without Validation* - Trusting user input without proper validation can lead to security vulnerabilities like XSS attacks - Always validate user data and never assume it is safe to use without validation Made with HARPA AI
Povilas, could you create a version of this article focusing on Filament. A "Top 'n' Filament Bad Practices" would be very welcome. A full course, perhaps, could emerge from this? 😊
I worked on 3cr+ data in a single table. It is also important to db partition and indexing. Also do not use any hashing in where clause like md5(). Also use cache mechanism By implementing these practice, data retrieval and manipulation become more streamlined, ensuring smooth and efficient database operations even at a large scale.
My "Bad practice" I used at the start of the product was to create all kinds of pricing with zero(around 9k pricing combinations with pricing plans and service plans). Now need to find a way to refactor it to stop creating that large amount of pricing without breaking the complete project. Because now those are the biggest tables in the project :(
I love the vintage design of your gum road website! One more bad practice I saw in projects in querying data directly from the view like {{ \App\Models\Posts:: newest()->limits(10)-get() }} in blade components
Yes, the violation of MVC became a "not so bad" practice and it's mentioned among the 17 in the tutorial. It used to be bad practice but then they released Livewire Volt... And turned MVC upside down :) With vintage theme, it's actually default gumroad :)
What do you use to write programming E-books?. People recommend Markdown but I find it cumbersome to think about its syntax as well the content you are writing
I'm guilty of sending back error code with 200 code with the message of the error, i don't know where i picked it up or started doing it. I even infected my Codeium AI helper with this disease
i think you shoud add another bad practise: especially in public method array as parameter it's bad for readeability and its shoud be replaced by object or DTO
When the one and only clean architecture is invented :) There are many architecture options. I've talked about them in courses like "How to structure Laravel projects" or "SOLID code in Laravel", and others.
@@bumblebity2902 It could be either Controller actions or Livewire actions. Imagine this situation: we have a URL like /store/1/show, where we display a store using its ID. If we didn't set up authorization for the "show" method, I could just change the ID in the URL to something else and see a different store that isn't mine. Another situation could happen with Livewire. For example, we have something like wire:click="delete(1)". I could easily right-click and choose "inspect element", then change it to wire:click="delete(2)", and this action would be performed instead.
Depending on where you work, some enforce returning 200 because they define the "resource" as the service that returns data you're trying to get. I fundamentally disagree with this approach, but that's the logic those types of places uses
@@LaravelDaily I have watched his video with some other videos but that's all just theory there isn't any detail tutorial to use octane in an actual Laravel working application
Because almost no one is actually using it. 99.9% projects don't need that kind of boost, the performance problems are usually inside the app. But you can Google something from spatie, I remember they mentioned using octane but don't remember if they released tutorials about it.
@@LaravelDaily I believe it. It's hard to predict every possibility in such a tool like quick admin panel. It's a good lesson which teaches us that there are always some tradeoffs, isn't it?
Bad practice: not using DI container for binding preconfigured instances. I've seen $stripe = new \Stripe\StripeClient(config('stripe.api_secret')); way too many times man. Another bad practice is using env() directly in your code without having a dedicated config in config/foobar.php. Just like not using DI, it makes overriding stuff more difficult. Especially when libraries do it, this is terrible
Why would you gracefully hide a serious system error (a model didn’t exist where it should)? If the system is broken, fix the system. Don’t hide the error!
![Digital Circus Episode 4 [TRAILER]](http://i.ytimg.com/vi/abZtsmMUbJo/mqdefault.jpg)
7:55 "the overall message is, always validate the data from your users and never EVER trust them" ... words to live by!
Bad pratices: run php artisan migrate:fresh in production
there is the Prohibitable trait
🎯 Key points for quick navigation:
00:00 *🚫 Worst Laravel Practices Overview*
- Definition of bad practices in Laravel
- Introduction to the top 5 worst Laravel practices
01:51 *⏱️ Bad Practice #1: N+1 Query*
- N+1 query is a major cause of performance issues in Laravel
- Solutions include using Laravel debug tools, proper eager loading, and prevention techniques
03:01 *💾 Bad Practice #2: Loading Unnecessary Data*
- Loading full relationships or unnecessary data can lead to performance degradation
- It's essential to only load the data that is actually needed
04:12 *🔄 Bad Practice #3: Not Checking Relationships*
- Failing to check relationships or objects can result in errors, especially when chaining methods
- Best practice is to validate the existence of objects before using them
05:21 *🚨 Bad Practice #4: Inconsistent API Status Code*
- Returning JSON responses with incorrect status codes can lead to confusion for frontend developers
- Consistency in API status codes, especially for errors, is crucial for clear communication
06:31 *🔒 Bad Practice #5: Trusting User Data Without Validation*
- Trusting user input without proper validation can lead to security vulnerabilities like XSS attacks
- Always validate user data and never assume it is safe to use without validation
Made with HARPA AI
Povilas, could you create a version of this article focusing on Filament. A "Top 'n' Filament Bad Practices" would be very welcome. A full course, perhaps, could emerge from this? 😊
Something to think about :) thanks for the idea
Bad Practice N. Not Subscribing to Laravel Daily.
I totally agree with you 😃
no doubt!
I worked on 3cr+ data in a single table. It is also important to db partition and indexing. Also do not use any hashing in where clause like md5().
Also use cache mechanism
By implementing these practice, data retrieval and manipulation become more streamlined, ensuring smooth and efficient database operations even at a large scale.
My "Bad practice" I used at the start of the product was to create all kinds of pricing with zero(around 9k pricing combinations with pricing plans and service plans). Now need to find a way to refactor it to stop creating that large amount of pricing without breaking the complete project. Because now those are the biggest tables in the project :(
I love the vintage design of your gum road website!
One more bad practice I saw in projects in querying data directly from the view like {{ \App\Models\Posts:: newest()->limits(10)-get() }} in blade components
Yes, the violation of MVC became a "not so bad" practice and it's mentioned among the 17 in the tutorial. It used to be bad practice but then they released Livewire Volt... And turned MVC upside down :)
With vintage theme, it's actually default gumroad :)
What do you use to write programming E-books?. People recommend Markdown but I find it cumbersome to think about its syntax as well the content you are writing
Yes I write in Markdown, got used to it. In Sublime text as editor. Early notes or plans I write in Google keep, without markdown there.
I'm guilty of sending back error code with 200 code with the message of the error, i don't know where i picked it up or started doing it. I even infected my Codeium AI helper with this disease
I just throw an exception, or let it be thrown and let Laravel return it, be it the api route or front route 😀
What do you mean 2xx response with error inside is bad? It successfully retrieved the error!
😂
2xx - success
4xx - client error
5xx - server error
you forgot the tags :D somebody already obviously didn't understand.
😂😂😂 Joker
Hahaha
i think you shoud add another bad practise: especially in public method array as parameter it's bad for readeability and its shoud be replaced by object or DTO
When you made video course about the one and only "clean architecture" on Laravel?
When the one and only clean architecture is invented :)
There are many architecture options. I've talked about them in courses like "How to structure Laravel projects" or "SOLID code in Laravel", and others.
@@LaravelDaily Clean architecture takes project structure to the next level. OOP and SOLID taking to the perfection with strict separation of concerns
Not using Authorization for actions, is also considered as bad practice
For what kind of actions?
@@bumblebity2902 It could be either Controller actions or Livewire actions. Imagine this situation: we have a URL like /store/1/show, where we display a store using its ID. If we didn't set up authorization for the "show" method, I could just change the ID in the URL to something else and see a different store that isn't mine.
Another situation could happen with Livewire. For example, we have something like wire:click="delete(1)". I could easily right-click and choose "inspect element", then change it to wire:click="delete(2)", and this action would be performed instead.
request->all() - Thanks master!
Depending on where you work, some enforce returning 200 because they define the "resource" as the service that returns data you're trying to get.
I fundamentally disagree with this approach, but that's the logic those types of places uses
Bad practice: applying htmlentities() twice instead of just once. Check your article page title ;)
Thank you, well noticed! :)
Fixed now.
Hey do you recommend Octane? How can we use it?
You need this fresh video by Aaron Francis: ruclips.net/video/YGBvdAWt0W8/видео.htmlsi=zXo9YF-rVy04wNeY
@@LaravelDaily I have watched his video with some other videos but that's all just theory there isn't any detail tutorial to use octane in an actual Laravel working application
Because almost no one is actually using it. 99.9% projects don't need that kind of boost, the performance problems are usually inside the app.
But you can Google something from spatie, I remember they mentioned using octane but don't remember if they released tutorials about it.
@@LaravelDaily thanks
If $request->all() is a bad practice why in Quick Admin Panel it is used so often?
Because that was the tradeoff we had to make to avoid other more important bugs.
@@LaravelDaily I believe it. It's hard to predict every possibility in such a tool like quick admin panel. It's a good lesson which teaches us that there are always some tradeoffs, isn't it?
Yes, Laravel is so full of tradeoffs.
Thank you, that's really helpful
thank you .. Long waited tips..
When your company's codebsse is guilty of all these😂😂
What is your company's product? Asking for a friend.
@harshmudhar96 only thing I can say is its animation related
Can you provide the link to your project?!
@droidTV-ij4ct oh sorry I can't
NDA
5:31 The classic indonesian api response
Bad practice: not using DI container for binding preconfigured instances. I've seen $stripe = new \Stripe\StripeClient(config('stripe.api_secret')); way too many times man.
Another bad practice is using env() directly in your code without having a dedicated config in config/foobar.php. Just like not using DI, it makes overriding stuff more difficult. Especially when libraries do it, this is terrible
The second one is included in the list in the article. The first one is pretty rare and does have that big impact imho.
U would cry if i saw the code that my company writes... (I do every day...)
Why would you gracefully hide a serious system error (a model didn’t exist where it should)? If the system is broken, fix the system. Don’t hide the error!
yeap, is_admin = 1 xD
... put the is_admin=0 into cookie and then use it from there 🤣