 I have been in the industry for quite a bit. Today I'm just going to speak a little bit about how you can abuse Laravel and why some people after being working with it for quite a bit will tell you what not to do, right? So I pretty much, I didn't prepare like a big presentation, I'm just going to tell you what my experience is and why I don't like doing these things this way nowadays. So one of the things that I will tell you not to do is like if you have worked with Laravel in the past, you might be familiar with these things. We have the facades, we have the helpers, containers, requests and eloquent. So the problem with these things is they are service locators, they are proxies. So when you use these things in your code, you pretty much are coupled to what Laravel does and you are not sure what you are getting out of these services. For example, if you are using the request, sometimes if you refer to the request out of the HTTP layer, what is going to happen is Laravel and a layer before, like sometimes I have seen people using the request helper within a service provider. So what happened is like at this level of the application, Laravel doesn't know what the request is. So the problem is like when Laravel doesn't know how to resolve a dependency, it just created out of a global dependency. So what happened is like if you are really down the layer, let's say you are four steps down, you have an object that you have a controller that the controller knows about the request, but then you delegate to a service. So some people what we'll do is like in these services, because they have access to these helpers and facade, they will call the request. So what they are getting down the road is just a global request. And more than that, your application is now coupled to an object that it shouldn't be coupled to that kind of object. So the same thing happens with helpers and the same thing happens with containers and requests. So I'm just going to go through a little bit of examples and I'm going to tell you why this thing is bad and how you can see in action. And as I said, yes. So I have this small example here. So I have this controller. Everybody can see this controller? So I'll be small. I don't even know how to get this. And I think if I did it, yes, yes. So you guys can see it, right? So as I said, if everybody is, if you have work with Laravel, you can do it. You can access the Laravel services through the helpers. You might achieve the same thing doing this. You can do the same thing doing this. You actually can do the same thing doing this and turn, right? So there is a problem with the Laravel community nowadays. I would say the Laravel community because the people who really lead the project in this case, we have Taylor, we have Jeffrey Way, and we have everybody, and they will tell you that this is right. This is the correct way to go, and this is what you should be doing. So the first thing to understand here is if we drop down a little bit down the road, if you go to the unit test level, it's like when you try to unit this particular piece of code, you are not going to be able to do it. The only way for you to unit this particular piece of code is if you go, and of course they will provide you with the test case class. Are you guys, who are familiar with Laravel now? Yeah? Few people, okay? So for the non-Laravelians, so Laravel provided a test case, it's just a small wrapper. For their application, actually we can see it here if I can find it, yes. So they just bootstrap the application, and they just give you an application. So what happened is a unit test, to unit test your code, to test your code, actually you will need to boot the application. So this is not a unit test anymore, and no matter what they can say to you, this is not. So why? Because when your test or your code or your particular object knows about the whole application, it's not a unit test anymore, and it's not a good code anymore. So what you can do to test this yourself and see how couple to Laravel you are, you can just create a dummy test, and you can of course extend from the PHP test case. Who is familiar with PHP unit here? Good. So when you extend from the test case, the PHP unit gives you, you don't have access to this kind of stupid things anymore. So then you will be able to understand what the issue is here. So if we try to call, let's go, I have this small test. So this test is extending Laravel, and of course it's making use of this refresh database trace that is just, it runs the migrations every time we run the test, and so on. So if we hit the route, what route we are heading, what is this, is here, one second. So I'm going to be working with this particular route, it's just a dummy controller that doesn't do anything. The purpose of this controller is just to show you how couple we are to Laravel when we just abide to the rules that they say that they are the best rules to follow. So I'm going to copy this route. I'm going to go to the test that Laravel extends. So if we run this test, if we really look, I mean, you see that the test is passing, right? Why it's passing? We are just asserting that the code that we get out of the controller is a 200, so every response that Laravel gives you with the controller is just transformed to a 200. So we can see her. Ah, here. Here. Yeah, let's copy this. Actually, I meant to use this one. So if we run the test, okay, we have a 500 now. The config wasn't spelled right. Yeah. You see, evidence have config, yeah. 19, 19, I think it was wrong. Config. 19. It went faster. Yeah, config isn't spelled right. Cool. Let's just forget about this one. Of course. So, if you see here, so we are just making sure that we are getting a 200 out of this controller and out of nowhere, we are getting our services. We are accessing a configuration out of a global object. So two things to see here is like, if you see this configuration here, we are importing even though we are working with a facade here, we are still working with a super global name space, which is bad too. Why is it bad? Because when the service container, how it works in Laravel is like, they will register all these facades for you automatically when it's bootstrapping. So this is going to be safe in the cache and you will have access to these services out of this global configuration. So the problem with this is like, sometimes when you are running this coding in the queue or in CLI, the application doesn't know how to resolve these configurations namespaces. So you will get errors like, okay, this object wasn't found. So this is the first step. So if you really want to do this this way, you can just make sure you import the whole namespace and you should be good to go. So you are not good to go there. It's a post-lash facade. Oh, yeah. I don't use the dev. I use PHP Storm, so that's it for me. So that's the first step, right? So something to see and to understand here about it is if we drop down a little bit on what is that code quality and what the object should do is like every dependency that our object is going to work with, it should be injected through the constructor, right? Because what we have here is just a hidden dependency that then you are, as I said, you are coupled to a certain particular implementation. So the way how you can achieve this in a better way, you can pretty much create a public asset. And I miss my PHP Storm. Construct. Just check this real quick. Bear with me, OK? So if we test the code again, everything is going to work the same. Actually, if you see it here, so we are getting just the application name, right? We can achieve the same information. We can do it with the facade, with the container. But you can actually do this in a different way. So we have the dependency there and we can do, and with any luck, we have the same information. What is the difference here? The difference here is we are working with a dependency injection. Now we have a way how to mark those dependencies where we are testing. So if we want to achieve what was your name again, my friend Ben? What Ben was saying, we can be really independent from a framework. So if you are familiar with Laravel, so you can go to, they have something called contracts. And you can actually, you can import the contract. And with any luck, we can have it the same thing. So as you can see, Laravel is an amazing framework. It is, that's why it's really famous. But the way how they handle dependencies and the way, I don't know, the habits that they are just promoting, they are really bad. So with this way, it's like we have a contract here, which is an interface. So if we implement this interface, we get the same result. So as you can see, we have one, two, three, four, five, six different ways how to resolve a dependency in Laravel. But the best way is going to be injecting your dependencies through the constructor, so you can have a proper composition within your objects. So if we see, now if we go and try to run the same test, we are testing the same. Let's just try to test on PHP unit. So therefore, we don't have access to Laravel in this case. So it's the same file, and we are just going to try to test the same particular method. So what I'm just going to encounter here is like, you have millions of errors, right? Why these millions of errors? Because in this case, the way how Laravel works, they need to be registered within the savings container, and this happens just when the application is being bootstrapped. And so therefore, we don't have access to helpers. We don't have access to configuration. We don't have access to anything. And this is when you realize how bad your code is becoming. So if you want to fix this thing within the approach that we were talking about, we can, where is it? Can you close the response? Yeah. OK, so this is the one that I need. Just close this one. This is the one I need. So we have the same errors, right? So how can we fix this problem? So we have been told that if we have the proper dependency injection, we can still test our code without changing our implementation. So the way how you can do that is if we refers to dependency injection approach, we can have this way. And now if we come to this particular test, we are going to see a different error, right? We'll see that we need to inject this guy. So if we go and try to inject it, so I think it will work. If I, it wouldn't work. So one second, OK, bear with me. App name. So this should be working. So this is how we achieve what is called a proper dependency injection approach. So we need to build our work files in such a way that all the dependencies that this file needs are passed down through the constructor. So another approach that I have seen within the Laravel community is like some people will inject the container. So this will work for you. It's a really bad approach because then you are creating just a factory here and now your controller knows how to build classes. So this is bad. So you can inject the container here. So while you inject the container, of course, the container is, the Laravel container is an amazing piece of code because it will resolve any object that you are passing in and it will resolve your dependencies. But having the container here wouldn't solve your problems. So but let me just give you this example. So we have the container. So we need to look if we check. Now we are in the test that we are sending the Laravel. So why? It's container, container. So you see how we can actually access the dependency to resolve our configuration file object. But this is a really bad approach because now your controllers, they know how to resolve services out of nowhere. And so this is something that you shouldn't do. But if we go to the test case where we are sending our PHP unit, sure enough, you can do the same thing here. So let's see how we can build this. Let's continue. I think this should work. Line to the server and then your controller is accepting two dependency. Oh, yeah. Yeah, yeah. Thank you, brother. Sure enough, we have the same thing. But this is how you also can abuse Laravel because now you are injecting the container. And even though when you might think, oh, yeah, of course I am injecting a dependency, now your controller knows about, have knowledge about your whole application. And last one, we have also the request here. So something that I have seen also is like if you can have access to the request, if you type in the request, in this case, Laravel, when you type in the request here within your method, you are actually getting the request that your application is receiving in that particular moment. You will know that that is the request you are getting and it was created for you to use it within this request lifecycle. So the problem when we have a beautiful helper here, we can access the request in this way. So the difference between those two particular calls here is like this request is going to be built for you out of the global configuration and you don't know whether it's the request that you are expecting or not. So it will be resolved for you and pretty much you will receive the information you are getting, but you are not working with the proper request that you were expecting. And it's the same issue when we use this request within our service provider or within our services classes because those requests are being created from global. So if you wanna know what I mean, if you go a little bit down this road, public, think index, no index. So this is when we create the request and I'm not gonna dig into dig with you guys because you're gonna fall asleep, but so we create the request there out of the global configuration. So this is bad too, so please don't use it. If you wanna use it, well, that's up to you, but my best advice is not to use it. And last one, but no less, it's eloquent. Eloquent is such an amazing piece of code too. Of course, there is a really strong opinion between what is ORM and CRM. I think it's CRM, I don't know how to spell it though. So by just imagine, who knows about ducting? Okay, so who knows about eloquent? So we know what we're talking about, right? So we have eloquent is an active record where the lower one is just a data mapper. So there is a really strong opinion that I didn't know about it until this eloquent bite my ass, actually. So yes, so how you can contain eloquent. So the way how I do it, how I do it is like, of course, if you have used eloquent, you pretty much know that if you can access the database in this way, and there you go. You have your data, you have everything. Everything is super nice. And you can do things like, even though the thing is like, in this particular field, if you see it there, you might assume that it's a boolean value, right? But because we don't know what we do is eloquent works with a material, it's called set attribute. So it doesn't know about types. So the problem is like, it will find the index and it will just update it for you and you will be good to go. So when you realize that you fucked up, it's like you were just charging less money in your subscription or you were giving, you were charging more taxes in somebody else's. Actually, you had this case where we were, we had a wallet implementation and because of this beautiful magic, we were just charging more fees, percentage fees in those wallets when we weren't supposed to do it. So coming back to this is like, you see that this particular piece of code is paying a boolean but you can actually do full here. I don't know what this is. I think you just done the first user. Oh wait, no, I think it's called user, yeah. So there you go. And you call this beautiful thing here. I don't know where you have an error that you don't know what you're doing. Of course, if you have luck enough, you have a proper constraint in your database or you are not gonna update, you are not gonna pass an string there. But yeah, so that's eloquent. So the way how I particularly use eloquent is I try to use as much accessors as I can. If we go to user, if I want to get the email, I wouldn't get the email out of the magic. I will create, so this is pretty much the same thing but now I have a type that's gonna tell me you either give me a string or a string. So then you are just pretty much making sure that you are getting the proper data. Another particular. So actually I also have like a similar issue to this but what I did was I declared a time trial PHP doc. Yeah, so PHP, yeah, it's okay. I mean the PHP doc blocks might help you out when you want to run like a static analyze or whatever. But the thing is like if you don't have a proper test suite or if you don't have a proper design and you are working with a legacy code and you don't know what you're expecting there, then that will help you. Like for example, those doc blocks will help you just for autocompletion or whatever. So you will might not. Actually you can, if you're working with something like PHP Store, if you don't have this method, you can pretty much declare the property here. You can just do like, I think it's property or whatever. I think it's property. Yeah, so you can, and you have the name there. So then you have the autocompletion in your ID but this is not type-sensitive. So this is how you can achieve this part. The other thing that I do is I have seen is like if you have come across any given Laravel application, you will see how people access those particulars. Eloquence call, they do the same thing, but they do it here. Now the problem is you will have Eloquence where it's in all around your application and you don't even know what the problem is. So my best suggestion for you is just create a repo. It's a repository, it's not a repository pattern. Like we know people who knows, doctor knows what a proper repository pattern I'm talking about, but we can actually encapsulate Eloquence logic behind a wrapper for us. So you can pretty much get, let's say you are injecting the repository, you can have repo and you can do the same call. So you can call statically your Eloquence in that repository, you can test it here in the database out of a proper feature test. And then you are sure that whatever information you are getting from that particular method is the one you are expecting. And in this file, you can mark it as we did with the configuration and then you know that your code works. But don't use Eloquence outside repositories because it will beat your ass. And yeah, any questions? I'll test it for you. So in Tinker just then when you created the user you set verified to the proof. And notice if you look at the SQL, it says verify equals foo that goes around it. We changed the value of verified string of ID and that worked but they actually set the value to ID because that's a bit more. No, because it's still a string. So it's expecting, I'm pretty sure, I don't know, I don't remember about this database but I'm pretty sure it's expecting a tiny int. So that's why the constraint is there. I was wondering when you look at the actual SQL that I have, it says equals ID, I was wondering where they get the value from. This one here. Evaluate as the ID of the user. That's interesting. That's something that stops it so. Yeah. So yes, so something that you can do is here if you are expecting a tiny int, I don't even know how big that goes but let's say you have your verification and you are thinking like, okay, I am gonna allow one for the user is verified or zero for when the user is not verified but you can do pretty much this. And if you see the verification value there is 99. So that's the problem when you are handling eloquent in when you don't know what you're doing. So the best way for you to do it is just learn how it works and then just learn how you can contain it because if you are working in a solo project, it's okay. You can do whatever the hell you want but if you have one more person working with you, you are gone. So you need to properly do it and you need to properly contain it. So in closing, there is nothing bad for this approach to be honest. The strong part of Laravel and actually why they gain the adoption is because of this. This is a really onboarding process but you shouldn't do it. So just learn how it works and just try to go under the hood and then just hate it as much as possible. All right, thank you. Thank you guys for the talk and here's your... Oh, my last one for the year. I have five already, I don't know, three or four.