Simplify CRUD with resource controllers There are a set of repetitive tasks that occur on most resources. If you wanted to display cameras on your web-application, you would most likely want to: View all Camera See a form to insert a new camera Process the camera insertion Retrieve a particular camera See a form to update a camera (with fields already pre-populated) Process the update Delete a camera https://www.dinocajic.com/laravel-p57-controller-middleware/ What if we stepped and looked at the characteristics of a camera, like the camera’s brand and model. We could have a resource controller for each of those as well where
Category: Laravel
Secure actions with controller-level middleware Where do you add your middleware? We looked at adding it to our routes file, but we also added it to our Kernel.php in a previous example. Now we’re looking to add it to our Controller? Won’t this get confusing? https://www.dinocajic.com/laravel-p56-dependency-injection-in-controllers/ If you need to freshen up on the middleware in routes topic, check out the article that I wrote on it when we looked at route groups. https://medium.com/geekculture/laravel-p54-route-groups-middleware-and-controllers-f41804f40d31 We looked at adding it in our Kernel file when we were implementing the throttle:web middleware. <?php namespace App\Http; use Illuminate\Foundation\Http\Kernel as HttpKernel; class Kernel extends HttpKernel { // … /** *
Inject services, unclutter your controllers Since we just tackled everything route related, the next logical step is to get into Controllers. There are those that would have argued that we should have covered migrations, Models and then Controllers/Routes/Views, and there’s no disagreeing with that statement. Maybe I should write two Laravel article series concurrently. In the routing concept, without getting too far into the weeds, the Controller comes next. https://www.dinocajic.com/laravel-p55-soft-deleted-models-in-routes/ It’s not that we haven’t covered controllers yet, we just haven’t dug into some of the more infrequently/complicated functionality yet. Most of the concepts that we have already covered in
Route to trashed records with confidence Running through a tutorial series like this isn’t as straightforward as it seems. You want to cover topics in a specific order and yet each time you get to a new topic, you realize that you need to cover something else in order to do it. For example, after going through some of the easier topics in Laravel, I figured we could tackle some of the topics on their own, like Routes, Models, Controllers, etc. I’m in somewhat of dilemma right now. The last topic of the route series that I wanted to cover
Organize routes, secure them, and keep controllers lean The final topic that I wanted to touch upon in the web.php file are routing groups. We’re not fully finished talking about routes considering that we really haven’t even touched on the api.php file, which is used frequently as well. https://www.dinocajic.com/laravel-p53-rate-limiting/ We looked at route groups in an earlier article. If you need a refresher, you may check it out here. https://medium.com/geekculture/laravel-p23-route-groups-8d4ce3e8e083 What I really wanted to focus on here is adding middleware to a group and grouping a specific controller. Applying Middleware to a Group To apply middleware to a specific group, you simply use
Throttle traffic, keep your API safe For the sharp-eyed readers, you might have noticed a method called configureRateLimiting in the RouteServiceProvider in our previous article. protected function configureRateLimiting() { RateLimiter::for(‘api’, function (Request $request ) { return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip()); }); } What this does is limits the user’s requests per minute. The default is set to 60 requests per minute. If you needed to modify the number of requests, this is where you would typically do it (i.e. change it from 60 to 100). https://www.dinocajic.com/laravel-p52-explicit-route-model-binding/ As you can see in the code, the rate limiter’s are defined in the RateLimiter facade’s for method. It accepts a rate limiter and a closure that returns
Take full control of model resolution in your routes When would you ever need to explicitly bind a model vs utilize Laravel’s implicit binding? A frequently asked question that I frequently find doesn’t have an appropriate, or simple enough, response. Because of that, I don’t see it used as frequently as it should be. https://www.dinocajic.com/laravel-p51-route-model-implicit-binding/ In the previous example, we used the following implicit route-model binding technique. use App\Models\User; Route::get(‘/implicit-binding/{user}’, function (User $user) { return $user; }); What if we wanted to only return the user that has been verified. What I normally see is the following code: use App\Models\User;
Let Laravel fetch your models automatically Now that we’re familiar with dependency injection, what else can we do with the concept? Can we “inject” our models, like the User model, into our route and then utilize model properties without instantiating the User model? How would we even do that? Don’t we need to first “find” the specific user before we can use the properties associated with that user? Believe it or not, Laravel has a way to get a user’s details without explicitly doing something like: User::find(24);. https://www.dinocajic.com/laravel-p50-routing-and-dependency-injection/ Implicit Binding We should understand that we do need to provide our model with an id at the very
Combine smart routing with seamless DI We’ve gone through a few dependency injection topics in the last couple of articles, but now we want to start getting more specific. We have finally entered a more advanced portion of Laravel and will start focusing on specific topics within specific areas of Laravel. The next few articles will deal with routing. In this article, we’ll focus on dependency injections in routes, which is really straightforward. https://www.dinocajic.com/laravel-p49-dependency-injection/ In your route you may type-hint any dependency into your callback signature. If you’re using controllers, the type hint will occur at the method level. use
Implement effective DI patterns for cleaner, testable Laravel code I hope that the last article made sense. Dependency Injection really is a simple concept. I feel like you should understand it in its entirety before you state that you know “Dependency Injection in Laravel.” Before we get into Dependency Injection again, you should understand Laravel’s service container. What is a service container in Laravel? It’s simply a tool that manages dependencies and it is this tool that actually performs the dependency injection. https://medium.com/geekculture/laravel-p48-dependency-injection-concept-high-level-php-concept-482e9f13d97b In the previous article, we looked at an extremely simple dependency injection example. <?php class Driver { private Car