Top 5 Laravel "Bad Practices" (My Opinion)

hello guys people keep asking me what are the best practices to do this or that in larl and larl as a framework is pretty flexible so often there are no best absolute best practices but there are really bad practices that could cause performance security or architectural issues so I published an article on laral dailyc for premium members this time collecting 17 so far bad practices or things I identified as bad practices and in this video I will read you first five of them which I consider the most kind of the worst bad practices other ones are debatable maybe not so bad practices and this is actually based on my older ebook so two years ago I experimented with gumroad and released separately from laral dailyc separately a few products on gumroad just to try it out and one of those was a collaboration with another person Bilal hayar and together we compil 35 practices so I decided to kind of refresh it to larl new versions and removed the ones that were really kind of debatable and not so bad practices so let's talk about the worst ones in this video and at the end of this video I will actually talk about gumro separately about my story how to sell products there so if you want to sell your own ebook or software it's really easy to start on gumroad and I will briefly show you how at the end of this video anyway what is a bad practice it's some piece piece of code which currently or potentially in the future would cause really bad damage like security issues performance issues or maintainability issues for other new developers so this is my personal definition of bad practice and bad practice number one is kind of elephant in the room n plus1 query is by far the number one reason for performance issues whenever I see that question on forums or somewhere to debug the slow laral application the classic example is from the doc so you need to eager load instead of doing book author you need to have book with here and then you avoid many queries and you can deal with those many queries on three levels so I identified first if you do have those n plus1 query problem you may find and fix them with laral debugbar or Alternatives like telescope Clockwork and others then also you can adopt a habit in your code to use eager loading properly or relative new addition in larl 8.43 from what I remember is preventing the lazy loading preventing the N plus1 query on service provider level locally so in case there is an N plus1 query happening Lille would detect and throw an exception and this article by the way will contain a lot of external links to read more about everything so that's bad practice number one bad practice number two is also related to eloquent but from another angle we can cause performance issues by download loading too much data from database into memory classical example is loading the full relationship although what you need is just the count of relationship or maybe one field of that relationship but you're loading all the data and Common Table For example may contain very long comments so that could totally pollute your memory a better example should be this with count because all you need is just a count here another example could be loading just the fields that you need so Select Title instead of loading all the posts which also can contain quite a lot of data if you load all the columns and both of those bad practices kind of you wouldn't feel that in the beginning this is a common feeling when you're starting the project you don't see any performance issues those performance issues start happening much later if you're lucky and the project takes off then with more simultaneous users and with more data performance issues would really bite you back so in terms of bad practice number two just load the data that you actually need bad practice number two is not checking the relationships or not checking the objects and chaining in laral in various forms again a classical example with relationship but with that idea I wanted to cover the general chaining so laral allows you to do something then another object then another object then maybe some function stuff like that and that works like magic but what if that project user is empty soft deleted or something like that then you get the classical error of property on null and there are various ways how to fix that for example you can use this PHP operator or with default on eloquent level I have a separate tutorial again the link is here but General the bad practice is not checking those intermediate objects another example when you load something from database you have first and then you immediately use the column from that first assuming that it always exists what if it doesn't in some cases you get exceptions in some cases you get empty values returned and then your users may be confused in the browser a better practice is just check all the objects and do something if something does not exist bad practice number four which is actually not only about laravel it's about generally building the apis but it's so common I've seen that a lot in laral API code if something goes wrong people still return Json with 200 status code or without any code here which means it would still return 100 and the error message the error fact is described in the body of Json this is a bad practice if you consider how frontend developer who is on your team or externally how they would feel when they get the 200 status code which means for them that it's successful but actually the code failed really really confusing and the problem is so common on the internet that it deserved some memes on the internet I found this one on Reddit and you may find other Alternatives also on internet so just be consistent with your API status code returns especially 200 versus errors like 400 or 500 codes and bad practice number five this is where I will switch to another browser when I'm logged in as a premium member so bad practice number five is trusting user data without validation this is again kind of a on topic with just a few examples from practical projects so classical xss attack is if you allow users to control the text inside of those brackets I'll actually Zoom that in so if someone in their profile in the about me profile is allowed to enter HTML they may also enter something like script alert something or something even worse in JavaScript code so use these only if you control the data inside or you properly validate that another example of not validating data enough is using request all which seems safe if you do it like this but this is actually with security issue let me explain so you have the form request class which validates some data but if you use request all here that request all will contain all the post data not only the fields that have been validated which means for example if someone passes is admin equals 1 as a part of that request and you happen to have fillable database field is admin then it doesn't matter if it is validated here or not it will still be passed as a parameter because you use request all instead here you should use request validated which will contain only the data validated in this form request class so these are just two kind of classical examples of that bad practice but the overall message is always validate the data from your users and never ever trust them and this is where we get to section number two of that article 17 Bad practices in total so this one is available only for premium members if you want to get that I will link that in the description below premium members get not only this article and other premium tutorials but also courses at this moment it's more than 60 courses on larl with thousands of members already so I'm not even really sure if I need to advertise that anymore my style is kind of publishing something for free on YouTube and stuff that we spend more time on with the team is for premium members only so for example section two we'll start with not so bad practice of not using route names this is debatable and if you don't use route names it will be kind of fine and you may not even notice but if you do notice it may be very inconvenient so practices like that will be listed below and now the final part of this video I promised you to talk about gumroad so a few years ago I experimented with that and released a few products two of them are ebooks and two of them were software products but basically it's the same thing gumroad allows you to upload some file or several files and make them downloadable for some price so here's how gumroad backend dashboard looks like for myself and here's how much I've earned in 2022 when I did advertise that now these days I don't advertise those products because they're kind of outdated so for you to have a ener feeling how to use gumroad you add product new product then for example let's take my ebook of freelancing this is actually maybe not that much outdated so you may still purchase that one if you wish but anyway you just add the product description then you add cover thumbnail product info then details of pricing and others then in content you actually upload the file and that's it basically if you want to start selling your info product like ebook or downloadable software for example like larel project I do recommend gumroad as it is easy to start at least it used to be in 2022 but it doesn't seem to be change at all since then but yeah going back to the main topic of this video bad practices in laral would you add something to that list of top five crucial bad practices that would kind of break the app or cause performance architectural or security issues let's discuss in the comments below that's it for this time and see you guys in other videos

Channel: Laravel Daily

Views: 19,109

Keywords:

Id: dSH4dyCQVas

Length: 10min 31sec (631 seconds)

Published: Thu May 02 2024