DEV Community: Kennedy Gitahi

Understanding Laravel Eloquent Relationships: From Basics to Polymorphic

Kennedy Gitahi — Sat, 09 Aug 2025 15:29:20 +0000

In the last two articles, we established a solid foundation with Laravel's MVC pattern and routing system. Now, it's time to tackle the heart of any data-driven application, the connections between your data.

Most applications don't just deal with a single type of data.

For example,

A blog can have posts that belong to users (writers or contributors), and each post can have multiple comments.
An e-commerce store can have orders that contain many products.

Laravel's Eloquent ORM makes managing these complex relationships intuitive and elegant.

If you've ever found yourself running multiple database queries to get related data or struggling to understand how to link your models, this guide is for you. We'll demystify Eloquent relationships and show you how to build a truly connected application with clean, readable code.

Why Use Eloquent Relationships?

Eloquent relationships are convenient, but beyond that, they are also a fundamental part of building an efficient and well-structured application.

Some of the main reasons to use them include:

Readability: They make your code more expressive. Instead of writing a complex query, you can simply write $post->user to get the user who authored a post.
Efficiency: They prevent the notorious "N+1 query problem", where you accidentally run one query to get a list of items and then N separate queries to get related data for each item (more on that below).
Maintainability: The relationship logic is defined once in your model, so you don't have to repeat yourself. If a relationship changes, you only update it in one place.

The Four Key Relationship Types in Laravel

Eloquent provides several types of relationships, but you'll usually use the four we discuss below the most. If you want to become an efficient Laravel developer, understanding them is the key to building almost any application.

1. One-to-One (hasOne / belongsTo)

This is the simplest relationship and the easiest to understand. It entails one model instance being associated with exactly one other model instance.

A classic example is a User model and a Phone model. Each user can have one phone, and each phone belongs to one user.

User Model (hasOne)

You would define the "hasOne" relationship on the model that "has" the related model. In our example, the User "has one" Phone.

// app/Models/User.php
public function phone()
{
    return $this->hasOne(Phone::class);
}

Phone Model (belongsTo)

You would define the "belongsTo" relationship on the model that "belongs to" the other model. The Phone "belongs to" a User.

// app/Models/Phone.php
public function user()
{
    return $this->belongsTo(User::class);
}

Database Migration

In your database migration file, you would set the foreign key (user_id) on the "phones" table:

// database/migrations/xxxx_xx_xx_create_phones_table.php
Schema::create('phones', function (Blueprint $table) {
    $table->id();
    $table->string('number');
    $table->foreignId('user_id')->constrained(); // Creates the foreign key
    $table->timestamps();
});

Alternatively, you can use "foreignIdFor" to define the relationship:

// database/migrations/xxxx_xx_xx_create_phones_table.php

use App\Models\User; // Assuming a User model exists

Schema::create('phones', function (Blueprint $table) {
    $table->id();
    $table->string('number');
    $table->foreignIdFor(User::class)->constrained(); // Creates the foreign key
    $table->timestamps();
});

Important Notes:

If you decide to use "foreignIdFor" in your migration, remember to import the "User" class at the top of the migration file or artisan will scream at you when doing the migration.

When you pass a model class to "foreignIdFor", it automatically generates the foreign key column name by appending _id to the snake-cased version of the model's table name (in this case, user).

For example, foreignIdFor(App\Models\User::class) will create a column named user_id.

You can provide a second argument to "foreignIdFor" to specify a custom column name if the default naming convention (the automatic column naming) is not desired.

One-to-One Relationship Usage Example

$user = User::find(1);
$phoneNumber = $user->phone->number; // Use this to access the phone number of the user

$phone = Phone::find(1); // Find a phone using its id
$userName = $phone->user->name; // Access the name of the user who owns the phone

2. One-to-Many (hasMany / belongsTo)

This is the most common relationship in Laravel and one that you will more than likely use the most.

With this relationship, one model instance is associated with multiple instances of another model.

For example, a User can have many Posts, but each Post belongs to only one User.

User Model (hasMany)

A user "has many" posts.

// app/Models/User.php
public function posts()
{
    return $this->hasMany(Post::class);
}

Post Model (belongsTo)

A post "belongsTo" a single user

// app/Models/Post.php
public function user()
{
    return $this->belongsTo(User::class);
}

Database Migration:

When creating a database migration for a one-to-many relationship, the foreign key (user_id) goes on the posts table. This makes sure that each post row in the database has a column for the associated user ID.

// database/migrations/xxxx_xx_xx_create_posts_table.php
Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->text('body');
    $table->foreignId('user_id')->constrained(); // Creates the foreign key
    $table->timestamps();
});

One-to-Many Relationship Usage Example

$user = User::find(1);
$posts = $user->posts; // Get all posts by this user (returns a Collection that you can loop over or transform in other ways)

$post = Post::find(1);
$authorName = $post->user->name; // Get the name of the post's author

3. Many-to-Many (belongsToMany)

The many-to-many relationship is very similar to the one-to-one relationship, but with a significant difference (you can guess this from its name!)

This relationship connects multiple instances of one model to multiple instances of another.

For example, a User can have many Roles, and a Role can be assigned to many Users.

Building many-to-many relationships require a pivot table (e.g., role_user) to store the intermediate records (more on this below).

User Model (belongsToMany)

A user "belongs to many" roles.

public function roles()
{
    return $this->belongsToMany(Role::class);
}

Role Model (belongsToMany)

A role "belongs to many" users.

// app/Models/Role.php
public function users()
{
    return $this->belongsToMany(User::class);
}

Database Migration

A separate pivot table is required when creating a many-to-many association.

// database/migrations/xxxx_xx_xx_create_role_user_table.php
Schema::create('role_user', function (Blueprint $table) {
    $table->foreignId('role_id')->constrained()->onDelete('cascade');
    $table->foreignId('user_id')->constrained()->onDelete('cascade');
    $table->primary(['role_id', 'user_id']); // Compound primary key
});

Many-to-Many Relationship Usage Example

//Get a specific user using their id
$user = User::find(1);

// Get the name of each role for the user (use a loop because there are potentially multiple roles assocuated with a specific user)
foreach ($user->roles as $role) {
    echo $role->name;
}

// Attaching and detaching relationships on the pivot table
$user->roles()->attach($roleId); // Add a role
$user->roles()->detach($roleId); // Remove a role
$user->roles()->sync([1, 2, 3]); // Sync roles to a given array of IDs

A Closer Look at Pivot Tables

When dealing with a many-to-many relationship, a dedicated "pivot table" (also known as an intermediate or join table) is necessary. This table sits between the two models and stores the foreign keys for both.

For example, in our example above, a User can have many Roles, and a Role can be assigned to many Users.

A pivot table, conventionally named role_user (the names of the two models in alphabetical order separated by an underscore), would store a record for each association.

This pivot table contains two foreign keys: user_id and role_id as seen in the migration above.

Understanding this, the question becomes: Why not just add role_id to the users table?

Because a user can have multiple roles, a single role_id column wouldn't be enough.

The pivot table allows you to have multiple rows for a single user, each corresponding to a different role. This is the key to managing many-to-many relationships in a relational database.

Here’s a visual representation of how a pivot table connects two models:

The role_user pivot table records that Alice (user_id 1) has two roles (Admin and Editor), while Bob (user_id 2) has one role (Editor).

Eloquent automatically handles the interactions with this pivot table behind the scenes. When you call $user->roles, Eloquent knows to look for the role_user table, find all entries with the matching user_id, and then fetch the corresponding Role models.

You can also access the pivot table columns directly via the pivot property on the related model:

// Assuming the pivot table has an additional column, e.g., 'expires_at'
foreach ($user->roles as $role) {
    echo $role->name . " expires at " . $role->pivot->expires_at;
}

This simple, elegant design is what makes Laravel's "belongsToMany" relationship so powerful and easy to use.

The N+1 Query Problem and Eager Loading

The N + 1 problem is one of the most important concepts to grasp. Imagine you have a list of 100 posts, and you want to display the author's name for each one.

The N+1 Problem (Lazy Loading):

// Fetches 100 posts
$posts = Post::all();

// A separate query runs for EACH post to get the user
foreach ($posts as $post) {
    echo $post->user->name;
}
// Total queries: 1 (for posts) + 100 (for users) = 101 queries

Now, consider an ecommerce store that needs to fetch hundreds of products, each with multiple pieces of data (SKU, price, shipping cost, multiple colours, multiple sizes, etc.)

Fetching data like this is very inefficient and slow, and will have significant implications, especially if you pay for compute, bandwidth, and how much data you fetch from the database.

The Solution (Eager Loading):

Eloquent provides the 'with()' method to "eager load" related data. This fetches all the posts and all their related users in just two queries.

// app/Http/Controllers/PostController.php
public function index()
{
    // Fetches 100 posts AND all their related users in just 2 queries
    $posts = Post::with('user')->get();

    return view('posts.index', compact('posts'));
}

Important Notes:

You can provide "with()" with an array for eager loading multiple relationships at once

Here is a code example (consider a Post that has author and tag relationships):

// Eager load both the 'author' and 'tags' relationships
$posts = Post::with(['author', 'tags'])->get();

You can also eager load nested relationships using dot notation. This is known as Nesting Eager Loading. For example:

$posts = Post::with(['author', 'comments.user'])->get();

In the example above (nested eager loading), Laravel will:

Fetch all posts from the database.
Fetch all authors for those posts (in a single query).
Fetch all comments for those posts (in a single query).
Fetch all users for those comments (in a single query).

Eager Loading Usage In the View

@foreach ($posts as $post)
    <div>
        <h2>{{ $post->title }}</h2>
        <p>By: {{ $post->user->name }}</p> {{-- The user is already loaded! --}}
    </div>
@endforeach

4. Polymorphic Relationships (morphTo / morphMany)

The fourth type of relationship you need to know about is the polymorphic relationship.

Think about this:

What if a model, like a Comment, could belong to more than one type of model? For example, a comment could be left on a Post or on a Video.

This is a job for polymorphic relationships.

Let's look at some code.

Comment Model (morphTo)

// app/Models/Comment.php
public function commentable()
{
    return $this->morphTo();
}

Post & Video Models (morphMany)

Both the Post and Video models define the morphMany relationship.

// app/Models/Post.php
public function comments()
{
    return $this->morphMany(Comment::class, 'commentable');
}

// app/Models/Video.php
public function comments()
{
    return $this->morphMany(Comment::class, 'commentable');
}

Polymorphic Relationships Relationship Usage Example

$post = Post::find(1);
$postComments = $post->comments; // Get all comments for the post

$video = Video::find(1);
$videoComments = $video->comments; // Get all comments for the video

$comment = Comment::find(1);
$commentParent = $comment->commentable; // Can be a Post or a Video instance!

Conclusion: Build Connected, Efficient Applications

Eloquent relationships are a gateway to building powerful, clean, and performant applications in Laravel.

By defining your data connections clearly in your models, using eager loading to prevent performance issues, and understanding advanced concepts like polymorphic relationships, you'll write less code, prevent common bugs, and make your application a joy to work on.

Take some time to practice these concepts. Try building a simple blog system or an e-commerce platform and use relationships to connect your data. You'll quickly see why Eloquent is one of Laravel's most beloved features.

What's the most complex relationship you've ever built with Eloquent? Share your experiences and tips below!

Stay tuned for the next article, where we'll dive into Laravel validations and form requests.

We briefly touched on this in our MVC article, but we will dive in deeper next week. Keep following along on our journey to becoming better Laravel developers!

How Well Do You Know Laravel's Routing System?

Kennedy Gitahi — Wed, 30 Jul 2025 19:02:03 +0000

In our last article, we demystified Laravel's MVC pattern, establishing a foundation for cleaner, more organized code. Now, let's talk about how requests actually find their way to those well-structured controllers and views: Laravel's incredibly flexible routing system.

While "Route::get('/hello', ...)" gets you started, a growing application demands more. If you've ever wished for better URL organization, struggled with passing data through URLs, or wanted to protect certain parts of your app, this guide is your next step.

We'll explore Laravel's routing system beyond the basics to help you build more robust and user-friendly applications.

The Heart of Your Application's Navigation: routes/web.php

At its simplest, a route tells Laravel: "When a user visits this URL with this HTTP method, execute that code."

Most of your web-facing routes will live in "routes/web.php".

However, for API routes, Laravel uses "routes/api.php", which comes with the api middleware group by default.

Here's a quick recap of the fundamental HTTP methods you'll use:

GET: Retrieve data (e.g., "Route::get('/products', ...)" to show a list of products).
POST: Send data to create a new resource (e.g., "Route::post('/products', ...)" to create a new product).
PUT/PATCH: Update an existing resource (PUT for full replacement, PATCH for partial updates).
DELETE: Remove a resource.

A basic route might look like this:

// routes/web.php

// Import controllers
use App\Http\Controllers\HomeController;
use App\Http\Controllers\ContactController;

Route::get('/', [HomeController::class, 'index']);
Route::post('/contact', [ContactController::class, 'submitForm']);

// For simple static views, use Route::view()
Route::view('/welcome', 'welcome'); // No controller needed!
Route::view('/about', 'about', ['company' => 'MyCo']); // Pass data to view

1. Dynamic URLs with Route Parameters

Applications aren't static because you'll often need to capture segments of the URL as data. You capture these URL segments using parameters.

Basic Parameters:

You define a parameter using curly braces "{}".

// A route to show a specific product by its ID
Route::get('/products/{id}', function (string $id) {
    return "Displaying product with ID: " . $id;
});

// Or, ideally, with a controller
use App\Http\Controllers\ProductController;
Route::get('/products/{id}', [ProductController::class, 'show']);

If you use a controller, you would have this in your "ProductController@show" method:

// app/Http/Controllers/ProductController.php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class ProductController extends Controller {
    public function show(string $id) {
        // Fetch product from DB using $id
        $product = Product::findOrFail($id);

        // Show the product
        return view('products.show', compact('product'));
    }
}

Optional Parameters:

You can make a parameter optional by adding a "?" after its name and providing a default value in your function signature.

Route::get('/users/{name?}', function (?string $name = 'Guest') {
    return "Hello, " . $name . "!";
});

// /users -> Hello, Guest!
// /users/Alice -> Hello, Alice!

In the above code, we provided "name" as an optional parameter and "Guest" as the default value for it.

Regular Expression Constraints (Using "where"):

Sometimes, you need to restrict the values a parameter can match. For instance, an ID should always be numeric.

The "where" method allows you to apply regular expressions that help apply constraints to your URL values so you always receive parameters that satisfy these constraints.


// Only match if {id} is one or more digits

Route::get('/products/{id}', [ProductController::class, 'show'])
    ->where('id', '[0-9]+');

// Only match if {slug} contains letters, numbers, or hyphens
Route::get('/blog/{slug}', [BlogController::class, 'showPost'])
    ->where('slug', '[A-Za-z0-9\-]+');

You can also define global patterns in "App\Providers\RouteServiceProvider@boot". This makes these patterns reusable across many routes.

public function boot()
{
    Route::pattern('id', '[0-9]+');
    Route::pattern('slug', '[A-Za-z0-9\-]+');
    // ... other patterns
}

2. Named Routes: Your Best Friend for URL Generation

Hardcoding URLs in your application is a recipe for disaster. In a typical application, you will use and reuse specific URLs in many places.

The problem with hardcoded URLs is that you have to find and replace all of them if you decide to change the URL.

Granted, any modern IDE or code editor allows you to do this easily, but wouldn't it be better to only change the URL in a single place?

Named routes solve this issue by giving your routes a unique identifier.

Route::get('/admin/products', [ProductController::class, 'index'])->name('admin.products.index');
Route::get('/admin/products/create', [ProductController::class, 'create'])->name('admin.products.create');
Route::get('/products/{id}', [ProductController::class, 'show'])->name('products.show');

What are the benefits of using named URLs?

URL Generation: You can use the route() helper to generate URLs dynamically:

<a  href="{{ route('admin.products.index') }}">View All Products</a>
<a  href="{{ route('products.show', ['id' => $product->id]) }}">View Product</a>

Redirections: Redirections are much easier to implement if you use named routes:

//In a function

    return redirect()->route('products.show', ['id' => $newProductId]);

Refactoring Safety: If you change the actual URL path (e.g, "/products/{id}" to "/items/{id}"), you only need to change it in your "routes/web.php" file and all calls to "route('products.show', ...)" will automatically generate the correct new URL.

Best Practice for Naming: Use the dot notation (. ) to logically group related routes (e.g., admin.products.index, admin.products.create). You typically use this dot notation on the name.

3. Route Groups: Organization & Efficiency

As your application grows, "routes/web.php" can become unwieldy and convoluted.

Route groups provide an easy way to organize your routes by allowing you to apply common attributes (like middleware, prefixes, names, or namespaces) to many routes at once, keeping your route files clean and maintainable.

// routes/web.php 

// Apply 'auth' middleware and 'admin' prefix to all routes within this group
Route::middleware('auth')->prefix('admin')->name('admin.')->group(function () {

// URL: /admin/dashboard, Name: admin.dashboard
Route::get('/dashboard', [AdminDashboardController::class, 'index'])->name('dashboard');

// URL: /admin/users, Name: admin.users.index
Route::get('/users', [AdminUserController::class, 'index'])->name('users.index');

// URL: /admin/users/create, Name: admin.users.create
Route::get('/users/create', [AdminUserController::class, 'create'])->name('users.create');
});

Common Group Attributes:

middleware(): Apply one or more middleware (e.g., auth, admin, throttle). Middleware provides a convenient mechanism for filtering HTTP requests entering your application (e.g., authentication, logging, CSRF protection, etc.).
prefix(): Add a common URI prefix to all routes (e.g., /admin, /api/v1).
name(): Add a common prefix to named routes (e.g., admin., api.v1.).
namespace(): Add a common PHP namespace to controller actions (less common in modern Laravel with fully qualified class names, but still useful for older projects or specific organizational needs).

Note: Read more about route groups on the Official Laravel documentation and here.

4. Route Model Binding: Effortless Data Retrieval

When I started my Laravel career, this was one of the things that confused me. This was until I realized that this is a Laravel superpower!

Route model binding automatically injects Eloquent model instances directly into your route or controller actions. This is very important for helping eliminate repetitive "findOrFail()" calls.

Implicit Binding (Automatic):

If your route parameter name matches an Eloquent model's "snake_case" name, Laravel will automatically try to retrieve the model instance.

Example:

// routes/web.php

use App\Http\Controllers\ProductController;

// Parameter name {product} matches the Product model
Route::get('/products/{product}', [ProductController::class, 'show']);

// app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

use App\Models\Product; // Don't forget to import your model!

class ProductController extends Controller
{
// Type-hint the Product model, Laravel does the rest!

public function show(Product $product)
{
    // If a product with the given ID (from the URL) exists,
    // $product will be an instance of App\Models\Product.

    // If not found, Laravel automatically throws a 404 Not Found exception.

    return view('products.show', compact('product'));
    }
}

Note: By default, Laravel finds the model by its primary key (id).

Customizing the Key (e.g., by slug):

You can tell Laravel to retrieve the model using a different column in your database (like a slug) by specifying the column name after the parameter.

// routes/web.php

Route::get('/blog/{post:slug}', [PostController::class, 'show']);

In the above example, "/blog/my-first-post" will retrieve the Post where slug is 'my-first-post'.

5. Resource Routes: RESTful Magic

For typical CRUD (Create, Read, Update, Delete) operations, Laravel provides "Route::resource()". This single line generates multiple routes adhering to RESTful conventions.

// routes/web.php

use App\Http\Controllers\PhotoController;

Route::resource('photos', PhotoController::class);

To see all the URLs created, run 'php artisan route:list' on your terminal. The results you get should map to something like this which shows you the routes generated:

Customizing Resource Routes:

You can customize your route resources using:

only() or except(): Use "only()" to generate only specific routes or "except(): to exclude some:


Route::resource('posts', PostController::class)->only(['index', 'show']);

Route::resource('comments', CommentController::class)->except(['create', 'edit']);

names(): Customize the generated route names:


Route::resource('users', UserController::class)->names([

'index' => 'users.all',

'show' => 'users.view'

]);

Important Note on Order: When mixing resource routes with custom routes, always define your custom routes before your resource routes to avoid your custom routes being "caught" by or matched with the more generic resource routes.

// CORRECT ORDER: Custom route first

Route::get('/products/featured', [ProductController::class, 'featured'])->name('products.featured');

Route::resource('products', ProductController::class); // This generates /products/{product}

6. Signed URLs: Protecting Public Links

Signed URLs provide a layer of security for publicly accessible routes that you want to protect from manipulation. Laravel appends a "signature" hash and verifies it whenever they are called. If the URL is tampered with, and therefore the signature is changed, the signature becomes invalid.

Common Use Cases:

Email Verification Links: Ensuring only the recipient can verify their email.
Password Reset Links: Preventing unauthorized password resets.
One-Time Download Links: Granting temporary access to files.

// routes/web.php

use Illuminate\Support\Facades\URL;

use Illuminate\Http\Request;

Route::get('/unsubscribe/{user}', function (Request $request, $user) {

    if (! $request->hasValidSignature()) {
        abort(401); // Unauthorized
    }

    // Logic to unsubscribe user here

    return "You have been unsubscribed.";

})->name('unsubscribe');

How to Generate a Signed URL

You can generate a signed URL using code similar to this:


// In a controller, email, or view:

use Illuminate\Support\Facades\URL;

use App\Models\User;

$user = User::find(1); //Or find by provided Id

$unsubscribeUrl = URL::signedRoute('unsubscribe', ['user' => $user->id]);


// You can also add an expiration time

$temporaryDownloadUrl = URL::temporarySignedRoute(

'download.file', now()->addMinutes(30), ['fileId' => 123]

);

You can also protect a route with a signature using the "signed" middleware:

Route::get('/download/{fileId}', [DownloadController::class, 'download'])

->name('download.file')

->middleware('signed');

7. Fallback Routes: Catching the Undefined

Sometimes, you want to provide a custom 404 page or catch all requests that don't match any other defined route. Laravel provides a "fallback" route that is perfect for this.

// routes/web.php

// Define all your other routes first...

Route::fallback(function () {
return view('errors.404'); // Or return response('Not Found', 404);
});

The fallback route should always be the very last route defined in your "routes/web.php" file. This is because it will catch any request that hasn't been handled by previous routes. It will, therefore, stop routes below it from matching with any requests.

Optimizing for Production: Route Caching

For larger applications, Laravel allows you to "cache" your routes, compiling them into a single, faster file.

This can significantly speed up route registration in production environments.

To do this, run the following command in your terminal after defining all your routes:


php artisan route:cache

As a precaution, you should always run "php artisan route:clear" and "php artisan route:cache" whenever you make changes to your route files in production.

Go Forth and Route!

Laravel's routing system is incredibly powerful, offering far more than just mapping URLs to actions. By mastering route parameters, names, groups, model binding, and special routes like resource and signed, you'll gain immense control over your application's URL structure, enhance maintainability, and improve the user experience.

Take some time to experiment with these features. Try refactoring a portion of your existing "routes/web.php" file using groups or converting a manual "findOrFail" to implicit model binding. You'll quickly appreciate the elegance and efficiency Laravel offers.

What's your favourite Laravel routing feature that saved you a lot of time? Share your experiences and tips in the comments below!

In the next installment of our series, we'll dive into Demystifying Eloquent Relationships and Building Connected Applications, showing how Laravel's ORM elegantly handles data connections!

Edit: The next article in this series, Understanding Laravel Eloquent Relationships: From Basics to Polymorphic, is now live! You can read the article here. Don't forget to leave a comment!

Mastering Laravel's MVC: A Practical Guide for Cleaner Code

Kennedy Gitahi — Wed, 25 Jun 2025 23:31:40 +0000

If you have ever felt lost in your own Laravel codebase or stared at a UserController method stretching hundreds of lines trying to decipher what's going on, you are not alone.

As Laravel developers, we've all been there. The good news is that Laravel's foundational Model-View-Controller (MVC) pattern is a crucial tool for helping you escape the spaghetti code jungle and build clean, scalable applications.

It is important to realize that understanding the MVC is more than an academic exercise. Doing so is a crucial skill that directly impacts your code's maintainability and your team's productivity. Let's demystify the MVC pattern and learn how to write cleaner Laravel code.

What is MVC, Anyway? (A Quick Refresher)

At its core, MVC divides your application into three interconnected parts, each with a specific responsibility:

Model (M): This is our data layer. Models represent your application's data and the business logic that interacts with it. In Laravel, this usually means your Eloquent Models, which communicate with your database tables.
- Responsibility: Data storage, retrieval, validation, and manipulation.
- Example: A Product model handles everything related to product data (fetching, saving, updating, relationships, etc,.).
View (V): This is the presentation layer. As their name implies, views are responsible for displaying data to the user. They are the front-facing part of your website or software built using Laravel. In Laravel, these are typically Blade templates (.blade.php files).
- Responsibility: Displaying data received from the Controller and handling the user interface.
- Example: A products/index.blade.php view displays a list of products.
Controller (C): This is the orchestrator or coordinator . Controllers handle incoming user requests, interact with Models to fetch or process data, and then pass that data to the appropriate View for display.
- Responsibility: Receiving requests, coordinating between Model and View, handling user input, redirecting to appropriate pagesand much more.
- Example: A ProductController would handle requests like "show all products," "create a new product," or "update a product."

Each of these parts can be much more complex than we have outlined here. This is just a general idea of what they are, what they are responsible for, and how you can use them.

As you develop more Laravel websites and build software using this framework, you will find new and interesting ways to use these parts and additional ways of getting them to work together in new ways.

Why Does MVC Matter for Clean Code?

The beauty of MVC, and perhaps the most important reason for following this pattern, is its separation of concerns. Each of the components we have mentioned above has a single, well-defined job. This separation leads to:

Easier Maintenance: When a bug arises or a feature needs to be changed, you know exactly where to look. Is it a data issue? Check the Model. Is it a display issue? Check the View. Is it a request handling issue? Check the Controller.
Better Organization: Your codebase remains structured and predictable, making it easier for new team members (or your future self!) to understand.
Enhanced Testability: Because components are independent, you can test them in isolation more effectively.
Improved Scalability: As your application grows, the distinct roles of MVC components prevent code entanglement and allow for more manageable expansion.

Practical Tips for Cleaner MVC in Laravel

Now, let's dive into practical ways to ensure your Laravel MVC components stay lean and focused.

1. Keep Your Controllers Thin (The "Fat Model, Thin Controller" Principle)

This is perhaps the most important rule for clean Laravel code. Your controllers should primarily act as traffic cops: receiving requests, delegating tasks, and returning responses. They should not contain complex business logic.

Bad Example (Fat Controller):

// app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\Request;

class ProductController extends Controller
{
    public function store(Request $request)
    {
        // Bad: Controller handles too much logic
        $validatedData = $request->validate([
            'name' => 'required|max:255',
            'price' => 'required|numeric',
            'description' => 'nullable',
            'image' => ['nullable', 'image', 'mimes:jpeg,png,jpg,gif,svg', 'max:2048'],
        ]);

        if ($validatedData['price'] < 0) {
            return redirect()->back()->withErrors('Price cannot be negative.');
        }

        $product = new Product();
        $product->name = $validatedData['name'];
        $product->price = $validatedData['price'];
        $product->description = $validatedData['description'];
        $product->image = $validatedData['image'];
        $product->save();

        // More logic could go here...

        return redirect()->route('products.index')->with('success', 'Product created successfully!');
    }
}

Good Example (Thin Controller with Logic in Model/Service):
PHP


// app/Http/Controllers/ProductController.php

namespace App\Http\Controllers;

use App\Models\Product;
use App\Http\Requests\ProductStoreRequest; // Using Form Request for validation

class ProductController extends Controller
{
    public function store(ProductStoreRequest $request) // Type-hinting Form Request
    {
        // Good: Controller delegates creation logic to the Model
        $product = Product::createProduct($request->validated()); // Static method on Model

        return redirect()->route('products.index')->with('success', 'Product created successfully!');
    }
}

Did you notice how the good example is significantly cleaner and easier to read? The controller's job is simply to initiate the action and return a response.

A Special Note on Form Requests

You might have noticed ProductStoreRequest in our "good" example controller. This isn't just a regular Request object; it's a Form Request!

Laravel allows you to create dedicated form requests using the code below:

php artisan make:request <name of form request object>

NB: It is good practice to end your form rerquest objects name with the word Request, e.g ProductStoreRequest.

This request object handles two critical concerns before your data even touches your controller method:

Validation: All your input validation rules live here. If validation fails, Laravel automatically redirects back or sends a JSON response. If you are using a form request when submitting a form, you can also use it to show the different validation errors that have come up after submitting the form
Authorization: You can define logic to check if the current user is authorized to perform the action. For example, you might not want a typical user to edit or delete a product; you might want to reserve that function for an admin!

Here's what your ProductStoreRequest might look like:

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Support\Facades\Auth; // For authorization checks

class ProductStoreRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize(): bool
    {
            if(Auth::check())
            {
                    return true;
                }

        // If no authorization passes (see below for additonal options), return false
        // By default, this will deny creation unless the user is explicitly authorized above
        return false;
    }

    /**
     * Get the validation rules that apply to the request.
     * 
     * @return array
     */
    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255', 'unique:products,name'],
            'description' => ['nullable', 'string', 'max:1000'],
            'price' => ['required', 'numeric', 'min:0.01'],
            'image' => ['nullable', 'image', 'mimes:jpeg,png,jpg,gif,svg', 'max:2048'],
        ];
    }

    /**
     * Get the error messages for the defined validation rules.
     * Optional: Customize the error messages the user will see when they submit a form with incorrect data.
     * This is usually very useful if you find that the default error messages aren't clear enough.
     *
     * @return array
     */
    public function messages(): array
    {
        return [
            'name.required' => 'A product name is required.',
            'name.unique' => 'A product with this name already exists.',
            'price.min' => 'The price must be at least :min.',
            'image.max' => 'The image may not be larger than 2MB.',
        ];
    }

    /**
     * Prepare the data for validation.
     * Optional: Use this method to modify request data before validation.
     * For example, trimming strings or setting default values.
     *
     * @return void
     */
    protected function prepareForValidation(): void
    {
        $this->merge([
            // Ensure price is float and not string
            'price' => (float) $this->input('price'),
            // Trim whitespace from string inputs
            'name' => trim($this->input('name')),
            'description' => trim($this->input('description')),
        ]);
    }
}

The option I have added above in the authorize method is a simple check if a user is authenticated. Since it will evaluate to true if a user is logged in, any logged-in user can create a product.

A second option would be to check for a specific role or permission. This is a common pattern for product creation and similar patterns.

You would typically have a roles/permissions package like Spatie Laravel Permission or a simple 'is_admin' column on the database or your User model.

// Example with a simple 'is_admin' flag on the User model
if (Auth::check() && Auth::user()->is_admin) {
    return true;
}

// Example with a permissions package (e.g., Spatie Laravel Permission)
if (Auth::check() && Auth::user()->can('create products')) {
    return true;
}

By offloading all the above responsibilities to Form Requests, your controllers remain incredibly clean and focused solely on coordinating the request.

2. Empower Your Models (The "Fat Model" Part)

Your Eloquent Models are more than just database table representations. They are the ideal place for:

Business Logic related to the data: Calculations, status changes, complex validations.
Relationship definitions: hasMany, belongsTo, belongsToMany, etc.
Scopes: Reusable query constraints.
Mutators and Accessors: Formatting data when setting or retrieving attributes.

Continuing from the example, in App\Models\Product.php:

// app/Models/Product.php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    use HasFactory;

    protected $fillable = [
        'name',
        'price',
        'description',
        'image'
    ];

    /**
     * Create a new product with basic validation.
     * This method holds the creation logic.
     *
     * @param array $data
     * @return Product
     * @throws \InvalidArgumentException
     */
    public static function createProduct(array $data): Product
    {
        if ($data['price'] < 0) {
            throw new \InvalidArgumentException('Price cannot be negative.');
        }

        return self::create($data); // Eloquent's create method
    }

    /**
     * Define a scope to get active products.
     */
    public function scopeActive($query)
    {
        return $query->where('is_active', true);
    }
}

While Models are excellent for data-specific logic, sometimes you'll encounter business logic that spans multiple models or involves a complex sequence of operations.

For these scenarios, consider introducing Service Classes. A service class is a plain PHP class where you encapsulate complex business rules. Your controller would then call a method on this service, which in turn interacts with your Models.

This keeps both your controllers and models focused on their primary responsibilities, offering another layer of abstraction for truly complex flows.

3. Keep Views Dumb (They Just Display)

Views should primarily focus on displaying the data they receive from the controller. Avoid any complex logic, database queries, or heavy computations within your Blade templates. Keep them as pure presentation layers as possible.

Bad Example (Logic inside the View):

  {{-- resources/views/products/show.blade.php --}}

<h1>{{ $product->name }}</h1>
<p>{{ $product->description }}</p>

@if ($product->price > 100) {{-- Logic to determine discount --}}
    <p>Price: ${{ $product->price * 0.9 }} (10% off!)</p>
@else
    <p>Price: ${{ $product->price }}</p>
@endif

{{-- Avoid doing things like this in the view: --}}
@php
    $relatedProducts = App\Models\Product::where('category_id', $product->category_id)->get();
@endphp
<ul>
    @foreach ($relatedProducts as $related)
        <li>{{ $related->name }}</li>
    @endforeach
</ul>

Good Example (Logic in Controller/Model, View for Display):
Logic in the controller

// app/Http/Controllers/ProductController.php

class ProductController extends Controller
{
    public function show(Product $product)
    {
        // Calculate discounted price in controller or (better) model accessor
        $displayPrice = $product->price;
        if ($product->price > 100) {
            $displayPrice = $product->price * 0.9;
        }

        // Fetch related products in the controller and pass to view
        $relatedProducts = Product::where('category_id', $product->category_id)
                                    ->where('id', '!=', $product->id)
                                    ->limit(3)
                                    ->get();

        return view('products.show', compact('product', 'displayPrice', 'relatedProducts'));
    }
}

View for display

{{-- resources/views/products/show.blade.php --}}

<h1>{{ $product->name }}</h1>
<p>{{ $product->description }}</p>

<p>Price: ${{ number_format($displayPrice, 2) }}
    @if ($product->price > 100)
        (10% off!)
    @endif
</p>

@if ($relatedProducts->isNotEmpty())
    <h2>Related Products</h2>
    <ul>
        @foreach ($relatedProducts as $related)
            <li><a href="{{ route('products.show', $related) }}">{{ $related->name }}</a></li>
        @endforeach
    </ul>
@endif

Notice how the clear separation of code makes each part instantly understandable and readable.

The view simply takes the data it's given and displays it, without making complex decisions or calling the database.

Next Steps: Apply These Principles!

Mastering MVC is a journey, not a destination. By consistently applying these principles, you'll transform your Laravel development experience, leading to more enjoyable coding sessions and more robust applications.

Challenge yourself:

Review one of your existing Laravel controllers. Can you move some of its logic into a Model or a custom Form Request?
Look at your Blade templates. Are there any complex computations or database queries that could be moved?

What's your biggest challenge or 'aha!' moment when it comes to organizing your Laravel code? Share your insights and tips in the comments below!

This is a continuing series. Stay tuned for the next article in this series, where we'll dive into Laravel's Routing System and show how to effectively guide requests through your newly organized application!

Edit: The next part in this series, Laravel's Routing System: Beyond the Basics, is now live.

PHP is Single-threaded, So How Does Laravel Handle Asynchronous Queue Jobs?

Kennedy Gitahi — Fri, 07 Mar 2025 02:11:10 +0000

As I dig deeper into Laravel, one thing I have always wanted to understand better is how it handles asynchronous queue jobs. As we know, PHP is a single-threaded language. This means that when a request arrives at a server, PHP processes it lineally from start to finish before moving to the next one.

This synchronous execution model works well for many scenarios, but it does not always serve the user well. For example, it can fall short when a server needs to perform resource-intensive tasks without making the user wait.

Laravel has a neat solution: its queue system, an elegant solution that brings asynchronous processing capabilities to PHP applications.

But how does Laravel accomplish seemingly asynchrnous operations in a single-threaded environment?

Understanding PHP's Single-Threaded Nature

Before diving into Laravel's queue implementation, it's important to understand what "single-threaded" really means in a PHP context.

When your application receives a request, PHP allocates a single execution thread to process it as mentioend above. This thread can only execute one instruction at a time in a set sequence until the entire script completes.

Unlike languages with native multi-threading capabilities, PHP cannot "spawn" additional threads within the same process to handle multiple tasks simultaneously.

This limitation becomes particularly problematic and obvious when your application needs to:

Send emails (especially many emails at the same time)
Process large files (like processing a podcast episode)
Generate reports (e.g. invoices or excel sheets)
Call external APIs with unpredictable response times
Perform resource-intensive calculations

Forcing users to wait while these operations complete would create a poor user experience.

This is precisely where Laravel's queue system shines.

How Laravel Achieves Asynchronous Processing

Queue Drivers: The Foundation

The foundation of Laravel's queue system is its queue drivers. These are storage mechanisms that hold your jobs until they're processed.

Laravel supports several of these drivers out of the box:

Database: Uses your application's database to store jobs (simple to set up but less performant at scale due to polling overhead)
Redis: High-performance, in-memory data store (excellent for high-volume queues and supports Redis Streams in Laravel 10+)
Amazon SQS: Cloud-based queue service (great for distributed systems)
Beanstalkd: Simple, fast work queue

Each driver has different performance characteristics and setup requirements.

However, Redis provides an excellent balance of performance and simplicity for most applications. This is the main reason why it is the recommended option by many experienced developers.

The Multi-Process Approach

What Laravel does brilliantly is circumvent PHP's single-threaded limitation by leveraging multiple processes instead of threads.

The fundamental concept works like this:

Your application dispatches jobs to a queue (stored in a database, Redis, etc.)
Separate PHP processes (queue workers) pick up and process these jobs
Multiple workers can run simultaneously, creating true parallelism

This approach allows your main application to continue processing requests while background jobs run independently in their own PHP processes.

Queue Workers: The Workhorses

At the heart of Laravel's queue system are queue workers. These are long-running PHP processes that continuously monitor your queues for new jobs.

Starting a queue worker is as simple as running:

php artisan queue:work

Once you run this command, it initiates a PHP process behind the scenes that:

Connects to your configured queue driver (Redis, database, etc.).
Polls for available jobs.
Retrieves and processes them one by one.
Continues this loop until it is manually stopped or hits a configured timeout.

Creating and Dispatching Queue Jobs

Laravel makes it remarkably easy to create and dispatch jobs.

Here's a simple example adapted from the example Laravel gives in its docs:

<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

class ProcessPodcast implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    protected $podcast;

    public function __construct($podcast)
    {
        $this->podcast = $podcast;
    }

    /**
     * Execute the job.
     */
    public function handle()
    {
        // Process the podcast...
        // This code runs in a separate PHP process
    }

    /**
     * Handle a job failure.
     */
    public function failed(?Throwable $exception)
    {
        //send notification of failure by logging or any other preferred way
        Log::error("Podcast processing failed: ". $exception->getMessage());
    }
}

Dispatching this job to the queue is as simple as:

ProcessPodcast::dispatch($podcast)->tries(5)->backoff(10);

This command will dispatch the job to the queue and set it to retry 5 times with a 10-second delay between retries. Retries are handled automatically by Laravel's queue system and ensure the job is retried up to the configured number of times ($tries) in case of failure.

According to Laravel's documentation:

When a job throws an exception but the exception threshold has not yet been reached, the job will typically be retried immediately. However, you may specify the number of minutes such a job should be delayed by calling the backoff method.

The backoff method prevents the job from being retried too often so it does not overburden your server. The default backoff is 10 seconds, the lowest it can be set to is 1 second, with the highest being 3600 seconds (1 hour).

With the single dispatch command above, Laravel serializes the job and its dependencies, stores it in your configured queue, and allows your application to continue processing the current request immediately.

You can also send a job to a specific queue by using the onQueue method:

ProcessPodcast::dispatch($podcast)->onQueue('high');

In this instance, the job will be sent to the high queue, which you can configure in your queue configuration file. Remember that you can push the same job to multiple queues, and the worker will process them in the order you specified:

ProcessPodcast::dispatch($podcast)->onQueue('high')->onQueue('low');

Doing this can be especially benefitial for instances where you want to prioritize or segment how jobs are processed. This is possible because the Laravel queue worker allows you to specify which queues it should process by priority.

For example, pushing jobs to a high queue can allow you to run a worker that gives them higher processing priority:

php artisan queue:work --queue=high

Scaling Beyond Single Workers

Horizontal Scaling with Multiple Workers

One of the most powerful aspects of Laravel's queue system is how easily it scales horizontally, which it does by allowing you to add more workers. This type of scaling allows running multiple queue workers simultaneously, with each processing different jobs independently:

php artisan queue:work --queue=high,low

Laravel's queue system is designed to handle high volumes of jobs by allowing you to scale horizontally by adding more workers to a queue so you can process jobs concurrently.

Laravel recommends that you start multiple queue:work processes if you would like to do this. To have multiple queue:work processes, you can either run each queue:work process in a separate terminal tab locally or configure your process manager to run multiple queue:work processes in production.

If you are worried about resources or too many workers, you can also use the --max option to limit the number that can run at the same time:

php artisan queue:work --max=10

Process Management with Supervisor

Production environments are different from development environments, and they require a different approach to managing queue workers. Since you do not always have access to a terminal or can keep an eye on your processes indefinitely in production, you need a way to keep your queue:work processes running.

Remember that a queue:work process can stop running for any variety of reasons, some of the most common ones being exceeding a worker timeout or executing the queue:restart command.

In these environments, Laravel recommends using Supervisor. This is a process control system that ensures your queue workers stay running. A typical Supervisor configuration for Laravel looks like this:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/your/project/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=forge
numprocs=8
redirect_stderr=true
stdout_logfile=/path/to/your/project/worker.log
stopwaitsecs=3600

Failed Jobs and Handling Retries

Jobs fail in the real world for a variety of reasons. If one of your queued jobs is encountering an error, you likely do not want it to keep retrying indefinitely because this will either exhaust your resources or lead to massive server bills.

Laravel provides a failed job system that allows its queue system to handle this elegantly and in a structured wayusing built-in retry logic.

When a job fails, Laravel will automatically store the job and the exception that was thrown in the failed_jobs table. You can then use the failed event to handle the failed job.

Laravel allows you to specify how many times or for how long a job may be attempted in several neat ways.

In The Terminal

The first is in the terminal. You can add the --tries switch to the following Artisan command:

php artisan queue:work --tries=3

This tells Laravel how many times to retry that job after the first failure. If a job exceeds its maximum number of attempts, it will be considered a "failed" job (see below for more details).

Supplying --tries=0 to the queue:work command will instruct your worker to retry the job indefinitely, which you might or might not want depending on your use case.

In The Job Class

Another option is setting the number of max retries in the job class:

<?php

namespace App\Jobs;

//Other code removed for brevity

class ProcessPodcast implements ShouldQueue
{
    //Other code removed for brevity

   // Set max attempts in the job class
    public $tries = 3;
}

Laravel 10+ also allows a backoff method inside the event class:

<?php

namespace App\Jobs;

//Other code removed for brevity

class ProcessPodcast implements ShouldQueue
{
    //Other code removed for brevity

    /**
    * Calculate the number of seconds to wait before retrying the job.
    */
    public function backoff(): int
    {
        return 3;
    }
}

Like in the command we saw earlier, the backoff method allows you to specify the number of seconds Laravel should wait before retrying a job that has encountered an exception.

For more complex retry logic, you can return an array of intervals:

<?php

namespace App\Jobs;

//Other code removed for brevity

class ProcessPodcast implements ShouldQueue
{
    //Other code removed for brevity

    /**
    * Calculate the number of seconds to wait before retrying the job.
    */
    public function backoff(): array
    {
        return [3, 30, 300]; // Retry after increasing intervals
    }
}

In this example, the retry delay is 3 seconds after the first try, 30 seconds after the second try, and 5 minutes (300 seconds) after the third try and each subsequent failed try.

Finally, you can also set the retry until time:

<?php

namespace App\Jobs;

//Other code removed for brevity

class ProcessPodcast implements ShouldQueue
{

public function retryUntil()
    {
        return now()->addHours(12);
    }
}

With this option, the job will be retried until the specified time. It is an excellent alternative to defining how many times your application retries a job before it fails, and it allows you to define a time at which the job should no longer be attempted.

By using the retryUntil method, the failing job will be attempted as many times as possible within a given time frame. In this example, the job will be retried until 12 hours have passed after the first failure.

Job Batching

Laravel 10+ offers a job batching feature that allows you to group multiple jobs into a single batch and process them together. This can be especially useful for processing large numbers of jobs in a single batch.

<?php

namespace App\Jobs;

use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;

$batch = Bus::batch([
    new ProcessPodcast($podcast1),
    new ProcessPodcast($podcast2),
    new ProcessPodcast($podcast3),
])->before(function (Batch $batch) {
    // At this point, we have created the batch but no jobs have been added...
})->progress(function (Batch $batch) {
    // At this point, a single job has completed successfully...
})->then(function (Batch $batch) {
    // At this point, all jobs have completed successfully...
})->catch(function (Batch $batch, Throwable $e) {
    // First batch job failure detected...
})->finally(function (Batch $batch) {
    // At this point, the batch has finished executing...
})->dispatch();

return $batch->id;

The batch's ID (a unique identifier we get through $batch->id), may be used to query for information about the batch once it has been dispatched.

You can then perform some action or run a callback when all the jobs in the batch have completed executing.

Job Chaining

Laravel 10+ also offers a job chaining feature that allows you to run a list of jobs in sequence.

Using the example provided by Laravel:

use App\Jobs\OptimizePodcast;
use App\Jobs\ProcessPodcast;
use App\Jobs\ReleasePodcast;
use Illuminate\Support\Facades\Bus;

Bus::chain([
    new ProcessPodcast,
    new OptimizePodcast,
    new ReleasePodcast,
])->dispatch();

Since this is a chain of jobs, subsequent jobs will not be run if one job in the sequence fails. For example OptimizePodcast will not run if ProcessPodcast fails.

Advanced Queue Management with Laravel Horizon

For completeness, we should mention Laravel Horizon, which is a beautiful dashboard and configuration system for your queue workers. It is an excellent option for developers running Redis queues.

# Install Laravel Horizon
composer require laravel/horizon

# Publish the Horizon configuration
php artisan horizon:install

# Start Horizon
php artisan horizon

Horizon provides:

Real-time queue monitoring
Job failure tracking and retry management
Worker balancing across multiple queues
Process scaling based on queue load
Tags for organizing jobs.
Metrics about queue performance.
Recent job details.

Performance Considerations and Best Practices

Error Handling

Error handling is a critical aspect of queue management because jobs are executed in the background, and unhandled exceptions can lead to silent failures. For this reason, you must implement robust error handling within jobs using try-catch blocks and logging.

Implementing try-catch blocks within the handle() method allows you to gracefully manage potential errors.

To follow the best practices, you must:

Log detailed error messages, including the exception trace, to make debugging easier for you and other developers who come after you.
Use the job's failed() method to perform specific actions upon failure, such as sending notifications or rolling back changes.
Avoid generic catch blocks and always catch specific exceptions whenever possible.

An example:

    public function handle()
    {
        try {
            $this->performSensitiveOperation();
        } catch (\Exception $e) {
            Log::error('Job failed: ' . $e->getMessage(), ['exception' => $e]);
            throw $e; //rethrow the exception so laravel knows the job has failed.
        }

    }

    public function performSensitiveOperation(){
        if(someFailureCondition){
            throw new \Exception("Sensitive operation failed");
        }

        // Perform your job logic here
        // ...
    }

    public function failed(\Throwable $exception)
    {
        Log::critical('Job failed critically: ' . $exception->getMessage(), ['exception' => $exception]);
        //send notification to developers.
    }

Job Size

Another great practice is keeping jobs focused and relatively small. The size of your jobs is important because large, monolithic jobs can tie up queue workers and server resources for extended periods. This can delay other jobs and potentially leading to timeouts.

To ensure the best performance, you should:

Break down complex tasks into smaller, more manageable jobs. You can then use batching or chaining to run the jobs as you wish
Ensure each job performs a single, well-defined task.
Avoid performing resource-intensive operations directly within the handle() method; delegate them to separate services or classes and batch or chain them.

Dependency Injection

This is a general OOP practice, but always remember to use dependency injection in job constructors. This is a best practice because dependency injection promotes code reusability, testability, and maintainability.

The best practices here include:

Inject services, repositories, and other dependencies into the job's constructor.
Avoid instantiating dependencies directly within the handle() method.

An example:

use App\Services\PodcastProcessingService;

public function __construct(PodcastProcessingService $podcastService, $podcast)
    {
        $this->podcastService = $podcastService;
        $this->podcast = $podcast;
    }

    public function handle()
    {
        $this->podcastService->process($this->podcast);
    }

Worker Memory Limits

Jobs that process large datasets or perform memory-intensive operations can exhaust worker memory, which can lead to weird side effects including crashes. To prevent this, you should configure appropriate memory limits for workers.

You can do this by:

Adjusting the PHP memory_limit setting in your php.ini file or within your Laravel configuration to accommodate the memory requirements of your jobs.
Ensuring your octane workers have enough memory when using octane.
Monitoring worker memory usage and adjusting the limit as needed.

Queue Prioritization

You should use queue names (e.g., high, default, low) to prioritize jobs. Doing this will help ensure critical tasks are processed before less important ones.

To follow this best practice:

Create multiple queues with different priorities.
Dispatch critical jobs to high-priority queues.
Use the --queue option with queue:work or Octane to specify which queues to process and in which order to do so.
Example dispatching to a high priority queue.

ProcessPodcast::dispatch($podcast)->onQueue('high');

Connection Pooling

You should also ensure proper connection pooling for database queues. Database queues can create a large number of database connections that can potentially exhaust available connections.

To follow this best practice:

Configure database connection pooling to reuse existing connections.
Use a database driver that supports connection pooling.
Optimize database queries within jobs to minimize connection usage.
Ensure your database server is configured to handle the expected number of connections.

Conclusion

Wow! That was much more information than I intended, but I think it was worth it.

Understanding Laravel's queue system is crucial for building robust and scalable applications. This is because the system allows developers and their code to elegantly overcome PHP's single-threaded limitation by using multiple processes rather than threads.

This approach allows Laravel applications to process resource-intensive tasks asynchronously without blocking the main request cycle. The effects is significantly improved application responsiveness and user experience.

By leveraging queues efficiently, which includes choosing the right driver, using Supervisor for stability as Laravel suggests, and adopting Horizon for monitoring, you can build applications that can handle high workloads gracefully regardlessof what those workloads are.

Remember that whether you're sending emails, processing uploads, or generating reports, Laravel queues are a powerful tool that provide the flexibility and power you need to get the job done efficiently.

Feel free to leave comments, corrections, or questions blow. A share would also be highly appreciated!

The Differences in Truthiness and Falsiness in JavaScript vs PHP

Kennedy Gitahi — Sat, 18 Jan 2025 10:39:13 +0000

Conditionals that check whether a value is true or false are a fundermental part of building any software, whether that is a website or a desktop application.

When working across different programming languages, understanding how they handle truthiness and falsiness is crucial for writing reliable code.

JavaScript and PHP, two of the most widely used languages in web development, handle these values and their checks differently. Let's explore these differences and their practical implications.

JavaScript's Approach to Truthiness

The biggest difference between how JavaScript handles truthiness and falsiness compared to PHP is how it treats empty arrays and objects.

Before we look at how it does that, let us look at some fundamentals.

JavaScript treats the following values as false:

const value1 = false     // Boolean false
const value2 = 0         // Number zero
const value3 = ""        // Empty string
const value4 = null      // null
const value5 = undefined // undefined
const value6 = NaN       // Not a Number

This includes their refs in frameworks like Vue.js:

const ref1 = ref(false)
const ref2 = ref(0)
const ref3 = ref("")
const ref4 = ref(null)
const ref5 = ref(undefined)
const ref6 = ref(NaN)

Confusingly, the following values and their ref equivalents are truthy:

const value7 = []        // Empty array
const value8 = {}        // Empty object
const value9 = "0"       // String containing "0"

Why is this the case?

It Has To Do With Memory

In JavaScript, empty arrays and objects are considered "truthy" because they are valid object references.

This is a fundamental aspect of JavaScript's type system and how it handles truthiness.

// Arrays and Objects are references to memory locations
// Even when empty, they are still valid references
const emptyArray = []    // Points to a valid array in memory
const emptyObject = {}   // Points to a valid object in memory

// When converted to boolean, any valid reference is true
Boolean([])  // true
Boolean({})  // true

// Compare this with actual falsy values
Boolean(0)         // false
Boolean("")        // false
Boolean(null)      // false
Boolean(undefined) // false

This is Deliberate

This design choice was made because:

An empty array/object is still a valid data structure that you can add items to
Empty arrays and empty objects are reference types (pointing to locations in memory) rather than primitive values
Having a reference, even to an empty container, is different from having nothing (null/undefined)

PHP's Different Perspective

PHP takes a more intuitive approach for many developers, treating empty data structures as falsy values.

To reiterate, empty arrays and empty objects are actually considered "falsy" in PHP and this one of the key differences between PHP and JavaScript.

Here's how it works:

// Empty array is falsy
$emptyArray = [];
if (!$emptyArray) {
    echo "Empty array is false"; // This will print
}

// Empty object is also falsy
$emptyObject = new stdClass();
if (!$emptyObject) {
    echo "Empty object is false"; // This will print
}

// All these are also falsy in PHP:
$false = false;     // Boolean false
$zero = 0;         // Integer 0
$zeroFloat = 0.0;  // Float 0.0
$empty = "";       // Empty string
$null = null;      // null
$emptyArray = [];  // Empty array

Checking for Truthiness and Falsiness in Empty Arrays and Objects in JavaScript

If you need to check truthiness and falsiness in JavaScript for these data types, you have to use the appropriate methods:

//For an array
[].length === 0              // true - explicitly checking emptiness

//For an object
Object.keys({}).length === 0 // true - explicitly checking emptiness

To do the same with refs:

const arrayRef = ref([]);
const objectRef = ref({});

// Correct way to check emptiness
if (arrayRef.value.length === 0) {
    console.log('Array is empty');
}

if (Object.keys(objectRef.value).length === 0) {
    console.log('Object is empty');
}

Checking for Truthiness and Falsiness in Empty Arrays and Objects in PHP

PHP's intuitive approach to checking truthiness and falsiness comes in handy for developers. Here's how it works:

// Empty data structures are falsy in PHP
$emptyArray = [];
$emptyObject = new stdClass();

if (!$emptyArray) {
    echo "This will execute because empty arrays are falsy\n";
}

if (!$emptyObject) {
    echo "This will execute because empty objects are falsy\n";
}

About PHP's empty()

Many developers use empty() to check for truthiness and falsiness, even for empty arrays and objects.

The PHP empty() function is a built-in function that checks if a variable is considered empty. Here's how it works:

// All these will return true with empty()
empty("");        // Empty string
empty(0);        // Zero as integer
empty(0.0);      // Zero as float
empty("0");      // String "0"
empty(null);     // null
empty(false);    // Boolean false
empty([]);       // Empty array
empty(new stdClass()); // Empty object
empty($undefined_var); // Undefined variable

// Examples of non-empty values
empty("0.0");     // false - string containing "0.0"
empty("string");  // false - non-empty string
empty(true);      // false - boolean true
empty(42);        // false - non-zero number
empty([0]);       // false - array with element


// PHP's empty() function is very versatile
$various_values = [
    "",        // empty string
    0,         // zero
    "0",       // string zero
    null,      // null
    false,     // boolean false
    [],        // empty array
    new stdClass() // empty object
];

foreach ($various_values as $value) {
    if (empty($value)) {
        echo "Value is considered empty in PHP\n";
    }
}

The key advantage of empty() is that it's safe to use on undefined variables. It does not trigger a warning like using isset() might (see below for explanation and example code). This makes it particularly useful in form handling:

// Safe form input checking
if (empty($_POST['username'])) {
    echo "Please enter a username";
}

// Checking object properties
$user = new stdClass();
if (empty($user->name)) {
    echo "Name is required";
}

It's worth noting that empty() is a language construct, not a function, which means you can't use it as a callback or variable function.

Here's an example showing why empty() can't be used as a callback or variable function, unlike regular PHP functions:

// This works with regular functions
$callback = 'strlen';
echo $callback("test");  // Works fine: outputs 4

// This will NOT work with empty()
$checker = 'empty';
$value = [];
echo $checker($value);   // Error: Call to undefined function empty()

// This also won't work in array_filter
$values = ["", "test", 0, 1, [], [1,2]];

// This will NOT work
array_filter($values, 'empty');    // Error

// Instead, you need to use a closure/anonymous function
array_filter($values, function($value) {
    return empty($value);
});

// Or with arrow function syntax (PHP 7.4+)
array_filter($values, fn($value) => empty($value));

Again, empty() is a language construct (like isset() or unset()), similar to operators or control structures, rather than a regular function.

When isset() Triggers a Warning

In PHP, isset() is a function used to determine if a variable is set and is not null.

isset() returns true if the variable exists and has a value other than null; otherwise, it returns false.

It does not trigger an error for undefined variables but can produce warnings when used on non-array types with array keys. This commonly happens when trying to use array keys with an uninitialized variable.

For example:

// Example: Triggering a warning with isset()
$data = null;

// Trying to check isset() on an undefined array key
if (isset($data['key'])) {
    echo "Key exists.";
} else {
    echo "Key does not exist.";
}

In this example

$data is null in this case, so it’s not an array.
Using $data['key'] triggers a warning because you’re attempting to access an index on a variable that is not an array.

If you do this, you will receive a warning like this:

Warning: Trying to access array offset on value of type null
Key does not exist.

To avoid this, you can add a type check before using isset():

<?php
$data = null;

if (is_array($data) && isset($data['key'])) {
    echo "Key exists.";
} else {
    echo "Key does not exist.";
}
?>

This helps you avoid the warning because is_array() verifies $data is an array before trying to access the key.

Practical Implications

These differences in how JavaScript and PHP handle empty arrays and objects, as well as truthiness and falsiness have significant implications for code design and debugging:

In JavaScript, you need to be explicit about checking for empty collections, which can make code more verbose but also more precise.
PHP's approach can make conditional logic simpler, but might require additional checks when you need to distinguish between different types of empty values.
When converting code between the two languages, these differences often require special attention to maintain the intended behavior.

Consider this common scenario:

// JavaScript - checking for empty data
function processData(data) {
    if (!data) {
        // This won't catch empty arrays or objects
        return 'No data provided';
    }
    if (Array.isArray(data) && data.length === 0) {
        return 'Empty array provided';
    }
    // Process data...
}

// PHP - checking for empty data
function processData($data) {
    if (empty($data)) {
        // This will catch empty arrays and objects
        return 'No data provided';
    }
    // Process data...
}

Understanding these fundamental differences is crucial for developer working with JavaScript and PHP, for example those using Laravel with React or Vue.

Doing so will help you write more reliable cross-platform code and avoid common pitfalls when switching between languages.

I hope this clears the confusion in using truthy and falsy valye in JavaScript and PHP. Have a question or comment? Feel free to elave it below. It would also eman the world to me if you shared this post here and on social media.

See you in the comment section!

Conditional Input Fields in Livewire: This or That but Never Both

Kennedy Gitahi — Wed, 06 Mar 2024 20:07:28 +0000

Have you ever had two conflicting pieces of data that you want to collect using the same form? OK, let me back up. I am building a car bazaar website and came across an interesting use case for conditional input fields in Livewire (I am using the TALL stack to build the platform).

Here’s what I needed: a form that collects car details, including whether the car is gas-powered or electric. Once you know the car type, use the form to collect the fuel or tank capacity if it is a gas powered car or the range if it is electric.

It is obvious that it would not make sense to collect the fuel capacity for an electric car or the range for a gas-powered one (OK, there are instances you may want to, but it is not a common scenario.)

Conditional Livewire Input Fields

To handle the above scenario using Livewire, you need to dynamically show and hide the relevant input fields (the fuel capacity and range inputs) based on the user's selection (gasoline or electric).

First, we have to run



php artisan make:livewire AddCar

to create the Livewire component and its corresponding Blade view. The component will be called “AddCar.php” and the Blade view will be “addcar.blade.php”. Your terminal will show you the file paths for the two files once they are created.

The first thing we will do is add the variables we will work with and that we want to save in our database to our component. Here’s a sample of what that might look like.

Livewire has a few interesting directives that we will use for this implementation. But first, we have to build the HTML form.

That is easy enough:

I am using radio buttons here, but you can do this with a select element and it would work the same.

Now, we have to bind each input to a livewire model. For this, we will use the “wire:model” directive and add it to the radio inputs.

If you have used Livewire before, you may know that “wire:model” only binds the data on submit or after taking an action with the form. However, we need the binding to happen immediately so choosing the right input field can work as expected. To make this happen, we instead use “wire:model.live”.

Conditional Rendering

Because we are using “wire:model.live” we know that “fuel” will be equal to either “gasoline” or “electric” once we click a radio button. These values are set by the “value” attribute added to our inputs.

Knowing this, we can now use “if” statements to show the right input field.

Here’s what we have added:

Conditional Fields: We use two @if statements to conditionally display the input fields based on the selected carType. If carType is "gasoline", the fuelCapacity input field is displayed.
If carType is "electric", the range input field is displayed. Save Button: Clicking the button triggers the saveCar method (defined in your Livewire component) to save the car information to the database.

We have wired the values entered into both fields to “fuelCapacity” and “range” that we can save to the database when adding a new car or editing an existing one.

You can also style the radio buttons, input fields and labels as needed for your project.

Here's how the logic works on my implementation:

Saving to Database

When creating your database, ensure the related values are nullable. In this example, fuel capacity and range are nullable. This means one can have a value while the other remains null.

If you do not do this, you will have an error saying you do not have a default value, you cannot save a null value or a similar error. If you leave the ability to add both, you will create the conflict this whole exercise was supposed to prevent.

Also, always validate all form data before saving it to the database. In this case, you want to ensure "fuel_capacity" is required and a number if you select "gasoline" as fuel, and "range" to be required and number if you choose "electric" as the fuel.

For this, you can use the "required_if" validation rule. Your validations will look something like this.

You can learn more about conditional validation on related fields here or through the Laravel documentation here.

Have you ever faced a situation where you had to use such an implementation? Let me know below!