 So, red food is controllers and cost structure. So, what exactly is red food and what it means? Like, actually, I didn't have the concept, so I had to look it up yesterday. So, it says that it's an architecture that's called red. It's like how we represent the data that is trust. You just adjusted a bit. So, sorry about that. No problem. I can breathe now. You're all closer. You have the courage. Okay, let's try and get you back in there. Good. Back in business? Looks so cool. It's all right. Codes break every day, so. Yeah. Let me just try this out. On again. No, don't do this to me. No. Okay. It might be my laptop. No, it's this laptop. Cool. All right. How I was saying is like, you know, we have been told like, hey, we have to build our APIs in a restful way. But actually, like, we don't know how to structure the code behind it. Or maybe we know and we don't have these concepts. We're clear, right? So, before dive into that way, we are going to see like a restful is just a representation of the stake between the browser and the user, right? Pretty much it says like we need to use the get method to request data from the server and put, pause and delete just to send data to the servers, right? So that's pretty much the basic concept about restful. I mean, so how can we apply this to our controllers, right? We can use so many frameworks, right? But you don't need to be like tied up to a framework. You pretty much can just build your controllers in such a way that your controllers abide to your endpoints. What it means is like you can be focused on your endpoints and if you have an endpoint to send data to persist data to the database, you should have like at least one method in your controller that controls your resource to represent these changes, right? So we can focus in the seven restful methods, which is index, shower, create, store, edit, and update, also destroy. So usually the index method is just to retrieve data from the database. Like if we have like, if we have, like see a dashboard and we need to see the users of the system, we have like, our first interaction is going to be like a grid list so we can retrieve this user from the server. So we have the show method, of course. It's like if we need to pretty much see more information from a given user, we have the create method, which is to show like a creation form to create new user and so on. So whatever you are seeing here is pretty much tied up to what our previous speaker was talking about. If we design our APIs in a such a way that is stressful, we can also implement these concepts in our code. What is the aim of this? We can keep the code clean, which is really very important. And we can, from there, we can like strive towards a better design in our domain. So another thing is like, the question that comes around is like, of course, if we have, like for example, if we have an user, we need to do some operations upon user resource. So this is easier, right? Because we can retrieve users and we can also save a new user and we can edit a given user. But what about if I have actions upon this user, right? What about if I have a subscription? What about if I have like a booking vouchers? What about if I have a given organization that it connects to our API, but we need to serve keys to these APIs? So how we go about these designs? So if we go back to our previous slide that says how we can abide to the seven principles controllers, it's like, if you have, for example, if you have a subscription controller, right? If you have a user that needs to subscribe to your system for some reason. So you can create yourself like a user subscription controller. So if you have this user subscription controller, you can pretty much abide to these seven methods in this controller and then you come back to the same establishment, right? I'm going to design my code in such a way how my API is working. So in this way, you can keep controllers clean and you can pretty much design your code towards your domain. So the main principle of this, I'm sorry, is like a lot of developer, right? As I am right now, which is the framework that I'm using the most at the moment. We have this error where we don't know where to put our code. We have no clue whatsoever or that was my mistake. So I started just putting all the logic that I wanted to put in the controller. If I want to do a calculation, put in the controller. If I want to parse some data, put in the controller. So what happens is like your controllers are going to end up in something called got object so that nobody knows what is going on there. So the aim of the controllers is just to take your response and to take your request and give you some response. There is nothing else that should happen in the controller, mostly like take the response, parse the data and send some, take the request, parse the data and send some response to the users, right? So how does, how can we design this thing? Well, if we abide to this method and if we abide to the solid principles, our controller will take the request. If we need to do some validation, we can create validation objects. If we need to parse some data, we can parse some data in the request and then we can again send the information back to the user towards our responses. So the question comes around here is like, again, what if I need a different object for a given method? What if I need to do something else in my controller? What is going to happen at this point? Well, if we go and design a new object injected to our controller, it's the object obligation or work to do this operation for us. It's not the controller. Of course, I'm not saying like if you have a controller and you just need to do a small operation, it's not allowed to have this small method in the controller. You can have something there. But after you are writing two, three methods apart from the seven principles, you will end up with a really, really bloody controller that is no longer maintainable and you are not going to have idea of what is going on there. So as I was saying, the controller is, they are not supposed to handle heavy logic, like validation, calculation or conversions or nothing related to that. Like if you need a validation, you request validation objects. You can inject this request in one of your methods and you can have this logic in some others. If you need to do the same thing, you can do with calculation and conversion. As I was saying, if you abide to the principles, solid principles and you inject these objects into your controllers, you will have a way to do this operation towards using other objects. So yes. So validation objects, they are like part of the request. You can create a request object that is going to be injected into your controller and on there is because this object extends from the request, you will have your data there and you can perform any validation that you want in the way that you need. Query to the base using repositories. There is a problem here that this is a good one and it's with a lot of our friends is like they have this active record. The problem with active record is really impossible to unitest those queries there. And if you have an active record in your domain, all of a sudden your domain which operates in user is going to know about everything else that is in somewhere else. I am a Laravel developer but this is something that we need to take care of. If you need to operate over the database, it's better if you inject a repository that does this function for you. Then you can unitest this code and you can have your logic in isolation so you are building your domain there. So if you are working in a user model, the user model doesn't need to know about subscriptions or for example, or vouchers or organizations. So that's why it's better to inject these services through repositories. And also the repo is the one in this case that's going to normalize or sanitize your objects. Because if we remember what a repository is supposed to do, a repo retrieve data from the database and give you an entity. If you are getting just one record from the database, you will get an entity. And this entity can be parsed, sanitized, validated, or whatever you need in that case. Same thing if you need more than one entity, you can have collection entities there. And this is the way kind of how doctrine works. So that's why they do this kind of thing. And this is very important. So don't make your controllers to handle heavy logic and just pretty much just have those controllers just taking your request and send the request to this whatever service you need and just sending back a response from them. So here like what about the routes? How I build my routes? Well, there are so many frameworks and libraries that I can help you with that. As I was telling you, like your routes are going to be pretty much your API endpoints. When we talk about RESTful, everybody's thinking, okay, this is just an API, right? But you can have an application, like an application that doesn't offer an API. And these controllers and this application can be treated in the same way. So for example, if you are serving... Again, if you are modifying a resource over the browser, right? And this browser, of course, in the browser we don't have the passion, we don't have the delete, and we don't have the path method, right? Because there are methods to be handled in the API level. Okay, if we don't have those there, we don't need them there. But we can still have our persistent layer which is going to be the store method or the update method. So we can trim out of the controllers, we can trim the methods that we don't need. And we abide to the principles which is stick with the seven methods that offers an API endpoint. So, okay, we can use a lot of REST symphony. There is something called the fastest route or whatever library out there. So you can use anything to build your routes, right? And this is pretty much more than suggestion. It's like, don't be afraid to create any objects, right? So the first thing that I have found in all my life is why I'm going to need to create a different controller when I can have all the logic in a controller in one place. So if I need to modify, if I need to maintain this code I'm just going to open one file, I'm going to have 2,000 lines in this file so I can maintain it, right? So this is going to be out of control and I have seen it in my life, I've seen it every other day and it's really difficult to maintain code that is not well-designed. So that's why we need to split our logic in different objects, right? So the usual resistance that I have come across is they are too complex. People who don't understand how objects relate between each other, the first thing they will tell you, okay, I'd rather have these procedures here in my controller and I don't care about your logic, right? So the logic is to spread out in different places and I can follow up. This is the things that you will find out there. Like why do I need to create an object with one method? And this is a good one, right? So you will see, for example, let's see, another example is if you are building an e-commerce and this e-commerce you need to create products and these products, of course, are going to have pictures and are going to have likes and whatever. So let's stick with the example between a product and a picture, right? So you can have a controller called Product Controller. This controller is just going to handle the basic information of the product, right? But you also can have one controller called Product Pictures Controller where you can have just one method or two methods. It's even possible to have just one callable method. We can use invoke in one controller and it's better to have 200,000 files that sense something that will tell you what the code is doing than have 2,000 lines in one controller or in one file. Where should I put the logic, right? Well, this is really difficult to answer. It's like, for example, what I usually do is I organize my code based on my domain. If I'm working with products, I will have like a root folder called Product and inside this product I'm going to have a HTTP folder which represents my HTTP layer and I will have controllers, middleware, requests and so on. If you guys are familiar with Laravel, it's pretty much what we have in the app folder by default. So pretty much I'm going to have one app folder per domain. Like if I'm working with, I don't know, if in a blog I will have a post. So this post, if the post has so much behavior, you will find when you need to create this domain section when there is a part in your system that is attracting a lot of behavior. Like again, if I go back to the e-commerce solution, right? What is the thing that you will have more behavior on is going to be on products. So you will have this domain created in your code and it's going to be pretty much where you are going to start from. The benefits that you will see about this approach is scalability. Why? Because if you need to modify something, if you need to change something in your domain, you just need to swap one controller, one method and you don't need to worry about anything else. And if you abide to the solid principles, you will inject the respective objects that you need to operate in these controllers. You will have them in the constructor and you can mock out these objects and you can unit test your code, which is the most important thing that you can do. So you will have a proper composition and you will remove the ability to introduce bugs by type hinting on real values. This is also, I mean, you can do type hinting, but the real benefit here is like it's really difficult when you have a got object, right, which is a file that has more than 1,000 lines, for example, well, 2,000 lines. Let's say that we have an e-commerce and our e-commerce is really big and we can allow our product model to have 2,000 lines, right? But it's easier to maintain a well-designed system where you have different objects that do different things than just putting everything as we usually do in the controllers and we don't care. So we are just going to put it here and we'll fix it later. And for me, it's just the pleasure of doing something different and I usually strive to do something different every day and if I learn something new today, I will do it tomorrow. So I have really a small code here. It's not like the biggest code ever. It's just a representation of how you can structure your controllers. Of course, if you have worked with Laravel, you will be familiar with this. If you have worked with symphony, the difference is symphony just get and post as a prefix. If you are operating in a get route, you will get indexed, but it's the same thing as you have here. You have the index method, which is the one that I was talking about before. Here you will use it to show your grids or something. You have the creation, you have the store method and you have the show and all those good stuff right there, right? So this is going to be product controller. So the one that I was telling you about is product pictures controller, which is the one that's going to handle my logic related with pictures and products. If you guys have worked in any commerce before, you realize that there is a lot of behavior related to a product. So it's really important that you can split out your logic and you can boost up your logic towards your demand, right? So what I was telling you about in Laravel, of course, these are Laravel related examples. Of course, you can achieve this with any framework or if you want to do it yourself. So we can see here, like in the product controller pictures, if you see here in the product controller, we are pretty much, if I can find it here, in the update, we are injecting just a lot of requests, right? It's just the plain object. Nothing is going to happen there. I'm just going to get the whole request and I will deal with it here inside my method, right? So of course, if you are anything like me, when you start doing something where you don't know a framework fully, the whole way to say something, you will put all your logic here, right? And that's perfectly fine, fine. But you have the option also here that to inject a different object, which is like, let's call it personalized objects. They call it request objects when you can operate before the request hits your route. So in Laravel, you can have product requests. You can have these amazing two methods to start with. You have an authorization layer where you can put anything you need there. If you return false from there, of course, that request is not going to hit your controller. And in the rules here, you can just pretty much type anything like something like, let's see, that the product title is going to be required. So if you are hitting the endpoint with a request that doesn't have a pause or a data call title there, I mean, the request is not going to hit your route. And yes, that's pretty much it. I'm sorry for the fast track, but this is like the second representation they do ever. So if you have any questions, just hit me up. Otherwise, thank you.