Accessors, mutators and casts

 Modern Laravel commonly uses Attribute.

protected function fullName(): Attribute
{
    return Attribute::make(
        get: fn ($value, $attributes) =>
            $attributes['first_name'] . ' ' . $attributes['last_name']
    );
}

Then:

$user->full_name;

A mutator transforms data when assigning it.

Casts convert database values into useful PHP types:

protected function casts(): array
{
    return [
        'is_active' => 'boolean',
        'settings' => 'array',
        'birth_date' => 'date',
    ];
}

Then:

$user->settings['theme'];

Scenario

If settings is stored as JSON in MySQL, an array cast means application code doesn't need to manually call json_decode() every time.

Read More

Global scopes

 A global scope automatically modifies every query for a model.

Example:

class ActiveUserScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        $builder->where('active', true);
    }
}

Then register it on the model.

Every normal query becomes effectively:

WHERE active = true

Scenario

Global scopes are useful for things such as tenant isolation or automatically filtering records.

However, I use them carefully because developers may forget that the condition exists.

A query can remove a global scope when appropriate:

User::withoutGlobalScopes()->get();

Read More

Local scopes

 Local scopes encapsulate reusable query conditions.

class Order extends Model
{
    public function scopePaid($query)
    {
        return $query->where('status', 'paid');
    }
}

Usage:

$orders = Order::paid()->latest()->get();

Parameterized scope:

public function scopeStatus($query, $status)
{
    return $query->where('status', $status);
}

Usage:

Order::status('pending')->get();

Real-project scenario

Instead of repeating:

where('status', 'active')

throughout controllers, repositories, and services, I can define:

User::active()->get();

This keeps business query logic reusable.

Read More

Lazy loading

 Lazy loading means the relationship is loaded when it is accessed.

$user = User::find(1);

$orders = $user->orders;

The orders query isn't executed until the relationship is accessed.

Advantage

It is convenient when the relationship isn't always needed.

Disadvantage

It can unintentionally create N+1 queries.

In performance-sensitive applications, I prefer explicitly deciding what relationships are needed:

User::with('orders')->find($id);

Laravel can also be configured to prevent accidental lazy loading during development, helping identify N+1 problems early.

Read More

Performance + Advanced Eloquent + Transactions

 

N+1 query problem

Interview answer

N+1 occurs when one query retrieves the parent records and then one additional query runs for each parent.

$users = User::all();

foreach ($users as $user) {
    echo $user->orders->count();
}

If there are 1,000 users, this can result in roughly:

1 query for users
+ 1,000 queries for orders
= 1,001 queries

Fix:

$users = User::with('orders')->get();

For large datasets, I also consider whether I actually need the complete relationship data.

For example:

$users = User::withCount('orders')->get();

Then:

$user->orders_count;

may be much cheaper than loading every order.

Read More

Eager loading and performance

 

Interview answer

Eager loading retrieves relationships upfront to avoid repeated database queries.

$users = User::with('orders')->get();

Instead of:

$users = User::all();

foreach ($users as $user) {
    echo $user->orders->count();
}

The second version can produce an N+1 problem.

Nested eager loading:

$orders = Order::with([
    'user',
    'items.product'
])->get();

Constrained eager loading:

$users = User::with([
    'orders' => function ($query) {
        $query->where('status', 'paid');
    }
])->get();

Scenario

On a page displaying 100 users and their orders, eager loading can reduce hundreds of relationship queries to a small number of queries.

Read More

Pivot tables

 A pivot table stores the relationship between two entities in a many-to-many relationship.

Example:

users
teams
team_user
-------
user_id
team_id
joined_at

Migration:

Schema::create('team_user', function (Blueprint $table) {
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->foreignId('team_id')->constrained()->cascadeOnDelete();
    $table->timestamp('joined_at')->nullable();

    $table->primary(['user_id', 'team_id']);
});

Access pivot data:

$user->teams->first()->pivot->joined_at;

When extra business logic/data exists, I may create a custom pivot model.

Scenario

For a subscription-like relationship:

user_id
plan_id
started_at
expires_at
status

The pivot is no longer just a simple linking table—it contains business information.

Read More