So instead of having a simple controller method that only interacts with a FormRequest and a Model, you've now added complexity with a superfluous Service class and a DTO. It may look cool, but using such a basic examples to try and demonstrate their usefulness is a mistake. public function store(StoreBlogPostRequest $request) { $blogPost = BlogPost::create($request->validated() + ['source' => BlogPostSource::App]); return new JsonResponse(BlogPostResource::make($blogPost), Response::HTTP_CREATED); } public function update(UpdateBlogPostRequest $request, BlogPost $blogPost) { $blogPost->update($request->validated()); return new JsonResponse(BlogPostResource::make($blogPost->fresh()), Response::HTTP_OK); } What should have taken 2-4 lines in 2 methods contained in 1 class became 6 methods inside 3 classes. There is a case to be made for Service classes and DTOs, but this is not one of them.
I think controller and service layer is enough for most of the laravel applications. Hence we are re creating all the method in the repository which is already available in the laravel eloquent model, it seems like a repetitive work without any additional benefit. We can just keep our controller clean and pass the business login to service class , then resolve the function my accessing database via eloquent models and then return the result to controller. in that way we can use the laravel already build eloquent powers easily and quickly.
Plz explain why you are using such complex things pipelines, ___invoke function, Just if condition for fillter , and if it is too mush code put it in traits
i have never worked with any php framework before. Its funny to see that back when i started learning php i designed a request handler that seems pretty similar to this piece of laravel.
I would add the transformation method to request classes. In my opinion you should not have to extend DTO classes when adding new pieces of code eg. API v2 instead you should have a method called asDto(or toDto) in the request class and call them instead of making X static factory methods. Overall great content :)
Hey! How do you approach having different validation rules in the store and update actions? For example, a StoreBlogRequest which marks all fields as required, VS an UpdateBlogRequest which doesn't (for example, you just wanna update the name). Would you create more than one DTO and mark the properties as nullable?
Hey there! It depends on the situation, generally speaking with updates I'd not go with nulls because partial updates are pretty sexy - if you use spatie/laravel-data - they handle it out of the box with Optional type hint
Hopefully if you're going to be making upstream requests on every page load (or every user login) the developer will be making sure to perform reasonable caching. Since this is Laravel it should be pretty configurable, but something to be conscientious of. Also, presumably the upstream service (e.g. growthbook, in this case) is utilizing standard HTTP cache headers that Guzzle can respect and cache centrally using the configured middleware (e.g. memcached if you're on a cluster or something).
Yikes. Model mutators and observers will be enough guys. But if you want to Over-engineer your code, then go on with dto or something like repository pattern. 😅
Really good man! I would like to know what you think about adding an extra layer: the repository. Because thats kinda whats going on my in job rn, laravel + service pattern + dto + repository, I feel like the Model itself could act as the Repository, what do you think?
It really depends on what you are looking for from the solution. I'd say - if you don't have a good reason to introduce a repository - don't do it. If you want to have more fine grained control over your persistence layer (i.e to handle CQRS more easily) go for repository!
17:20 - Shouldn't our DTO have a method like toArray so that we can manually avoid passing all the parameters? I mean, they correspond to the properties of the model. Or is this a bad practice? Like this public function toArray(): array { $properties = get_object_vars($this); $array = []; foreach ($properties as $key => $value) { $snakeCaseKey = Str::snake($key); $array[$snakeCaseKey] = $value; } return $array; } and then BlogPost::create($dto->toArray());
I didn’t know about pipeline but i think laravel provides the "when()" method on query builder instances. It’s simple and "eloquent" (pun intended 😂 ) i think but you probably already know about it. Your post seems to be for demonstrating the pipeline tool, thanks.
Mordo, if you use AWS there is a native way to integrate it though Event Bridge - almost no code solution and you don't pay for lambda invoke. Trust me mordziu I am an engineer. But well explained, thumb up
Nice tutorial! You can check ide-helper to generate model auto completion for properties. For dtos I find laravel-data by spatie a very good solution. Cheers
you can go further and return dto from custom request method (getDto()) which return dto class, inside that getDto method you can pass validated() as array to dto constructor, and write typed getter methods with default values (via ??) if api or app didnt receive some values from user
Hello, I was looking at your video channel. We may be helping a company that uses secure images to increase supply chain security and help cloud native development. Would you be willing to help try their software, make a video, and help show devs how to use their tools? This is not an offer, but just to start a conversation about your willingness to take on sponsorship. Please provide me with your email if you are interested. You'd have a chance to look at their technology and decide if it's the type of software that you'd be interested in covering in your channel.
Can this be implemented with repository pattern? to have for example in EmojiRepository in the function getFilterableEmojis() can we move here the logic with the pipeline to return just $filterable->builder->get() and in the controller to have like return EmojiResource::collection( $emojiRepository->getFilterableEmojis($request) );
When you have form request class included into ur method you dont need to do $request->validated cuz the data is already validated otherwise it throws validate exception until first line of code starts compile from function
Amazing stuff. I did sth weird to handle this . I added a helper method that returned an array with the key being the"Exception::class" and the value being either an array or a closure that returns an array as well this array always has a code and a message . this way I managed to also handle Laravel's own exceptions but your way of doing it is the Laravel way through the register method
