In-depth Laravel tutorials covering advanced topics, real-world examples, and best practices.
If you have a Middleware, where you should use it: in the Routes file or in the Controller? Here are the FOUR options.
Some time ago I posted a tweet that went viral: it was my vision of how typical Laravel SaaS could be created, by just using the packages and tools from the community. In this article, I decided to expand and actually show you how it can be done.
Imagine you want to load the Model with its related many models, but sort those related results by some column in that related DB table. How to do that?
Imagine you want to show some "global" data in the Blade: for example, the number of new users this week on the top navigation. Not sure what Controllers would the data come from? Then you can perform that action in the Service Provider, in three ways.
When importing data from CSV or another source, you may need to check every record whether it exists in the DB already, and then update that record, otherwise create a new one. There are multiple ways to perform it.
To add a record to the database, you may use one of two methods. What is the difference?
Sometimes you may encounter the situation that you need to return the same data on the web and via API. Should it be in the same or separate controllers? There are a few ways to handle it.
One of the most common questions about automated testing in Laravel is how to write tests for the usage of some external API. There are three ways to do that, and I will show all of those in this article.
When working with APIs, you often need to return an Eloquent response in JSON format. By default, Laravel transforms the response into JSON if you just return a Model or Eloquent Collection.
One of the most common questions I see about Laravel is how to structure the project. Or, in other words, where to put the logic out of the Controllers? In this article, I will try to show the options, trying to shorten one Controller method as an example.
