Forem: Ivan Mykhavko

$fillable Has No Context: Why Mass Assignment Breaks Down at Scale

Ivan Mykhavko — Thu, 02 Apr 2026 11:47:30 +0000

Mass assignment in Laravel is one of those things that feels like magic at first.
You see it in every tutorial: just toss your validated data into Model::create($data) or $model->update($request->validated()), set up your $fillable, and you're off to the races. For quick projects? It works. But when your app starts to get bigger, what once felt convenient can start to cause real trouble.

The Usual Approach

Let's be real-most controllers start out pretty much like this:

// OrderController.php
public function store(OrderStoreRequest $request): OrderResource
{
    $order = Order::query()->create($request->validated());

    return OrderResource::make($order);
}

It's clean, it's simple, and it just works. You throw whatever new fields you need into $fillable, and data slides right in.

But your Order model slowly grows. You add billing fields, delivery options, status flags, internal data. Suddenly $fillable looks like this:

protected $fillable = [
    'user_id', 'manager_id', 'number',
    'price_type_id', 'contract_code', 'currency_id',
    'address_id', 'status_id', 'direction_id', 'direction_type_id',
    'deliver_together', 'is_forced_processing', 'price', 'comment',
    'courier_date', 'courier_time', 'phone', 'first_name', 'last_name',
    'ip', 'user_agent', 'geo_location', 'finance_condition_data', 'is_from_api',
];

Twenty-four fields. Now ask yourself: what does Order::create($request->validated()) actually write to the database when called from the customer API? What about from the admin panel? From an internal backend action?

You don't know without digging into the request class, the validation rules, and then mentally subtracting fields that don't come from that particular endpoint. That's the real problem.

What Goes Wrong in Practice

You lose visibility fast

When you have three different endpoints that create an order - customer-facing, frontend panel, admin - each sets different fields. With mass assignment, the controller tells you nothing. You have to trace the full chain: controller → FormRequest → $fillable → model. And even then, you're guessing which fields actually come in from each context.

A new developer joins, gets a ticket "order is created with wrong status", searches for where status_id is set on Order... and finds nothing obvious. Because it comes in somewhere inside $request->validated().

The real problem: `$fillable` has no context

Here's the deeper issue. It's not really about how many fields are in $fillable. It's about what those fields mean and who is allowed to set them.

Look at the Order model again:

protected $fillable = [
    'is_forced_processing', // only admins
    'is_from_api',          // only customer API
    'manager_id',           // only internal, backend logic
    'status_id',            // should only be set internally
    'price',                // computed automatically
    // ...20 more
];

$fillable is a flat list. It has no idea who is calling Order::create(). It doesn't know if it's the admin panel, the customer API, or an internal action. Every field in that list is equally "allowed" for everyone.

So what do you put in $fillable? If you add is_forced_processing - it becomes fair game for any endpoint that calls Order::create($data). If you leave it out - your admin action has to use fill() + save() or Query::update() to bypass the guard. Either way, you're working around the model instead of working with it.

$fillable protects against fields that are not in the list. It doesn't protect against fields that are in the list but shouldn't be settable from a specific context. That's a different kind of protection - and it belongs at the endpoint level, not the model level.

What I Use Instead

The pattern that actually works: DTO + Action + explicit field mapping.

The controller converts the request to a typed DTO:

// OrderController.php (Frontend)
public function store(
    OrderStoreRequest $request,
    OrderCreateAction $orderCreateAction,
): OrderResource {
    $orderCreateDTO = OrderCreateDTO::fromRequest($request);
    $order = $orderCreateAction->handle($orderCreateDTO, $user->id);

    return OrderResource::make($order);
}

The DTO maps exactly what this endpoint cares about:

final class OrderCreateDTO
{
    public string $firstName;
    public string $lastName;
    public string $phone;
    public bool $deliverTogether;
    public ?int $directionId = null;
    public ?string $comment = null;
    public ?string $ip = null;

    public static function fromRequest(OrderStoreRequest $request): self
    {
        $self = new self();
        $self->firstName = $request->safe()->input('first_name');
        $self->lastName = $request->safe()->input('last_name');
        $self->phone = $request->safe()->input('phone');
        // ... etc, explicitly mapping
        $self->ip = $request->ip(); // this isn't user input :)
        return $self;
    }
}

The Action uses the DTO and writes exactly what it needs to:

final class OrderCreateAction implements Actionable
{
    public function handle(OrderCreateDTO $dto, int $userId): Order
    {
        // ... business logic: cart check, conditions, geo IP ...

        $order = Order::query()->create([
            'user_id' => $userId,        // from auth
            'status_id' => $statusEnum->value, // computed
            'price_type_id' => $userPriceType->id, // from profile
            'first_name' => $dto->firstName,
            'last_name' => $dto->lastName,
            'phone' => $dto->phone,
            'ip' => $dto->ip,
            // ...
        ]);

        return $order;
    }
}

Now it's obvious: user_id comes from auth, status_id is computed internally, first_name comes from the DTO. You don't have to trace three files to understand what the endpoint writes.

And the admin OrderCreateAction is a separate class with its own DTO - it sets different fields, without any chance of leaking between contexts.

The "Just Disable It" Way

Some devs go a different route: skip $fillable entirely and disable mass assignment protection globally. Nuno Maduro included this as an opt-in feature in his essentials package - the idea is that $fillable gives a false sense of security and the real protection should happen at the validation layer, not the model layer.

Usually, you add this to your AppServiceProvider:

Model::unguard();

Or using $guarded = [] on the model itself. Now every field is fillable, no maintenance of a list required.

This is a valid opinion. If you trust your FormRequests to filter input correctly, the model-level guard is indeed redundant. But it requires discipline: every endpoint must validate strictly, every new field must be accounted for in every request that touches the model. One missed $request->all() and anything goes through.

For me, unguarding is trading one problem (maintaining $fillable) for a bigger one (trusting every developer on the team to never pass unvalidated data to create()). In a large team, that's a lot of trust.

The Point

Mass assignment isn't broken. For simple CRUD, it's totally reasonable. But when your model has 20+ fields, multiple creation contexts, and a team of developers - explicit is better than magic.

The question to ask: can you open a controller method and immediately know what fields get written to the database? If the answer is "no, I need to check $fillable and the FormRequest and hope nothing slips through" - that's the problem.

DTOs and Actions add some boilerplate. But they make the code honest: each endpoint writes exactly what it says it writes, nothing more.

TL;DR

Mass assignment with $fillable is fine for small, simple apps.
When things grow and your models pile up the fields, you lose track of what's really getting written.
The issue isn't just field count; it's that $fillable has zero context. Anyone can set anything on accident.
Use a DTO per context to map request fields explicitly, and an Action to write to the model with explicit field names.
The best test: when you look at a controller, do you know-without checking three files-exactly what's hitting the database? With mass assignment, probably not. With explicit mapping, you always do.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

PHP Enums Are Not Your Bottleneck (Here's Proof)

Ivan Mykhavko — Wed, 04 Mar 2026 11:59:40 +0000

When you're building a large export - say, 50_000 order items, you start looking at every part of the code and wondering: what's slowing this down?

Here we have some order item export simplified code:

final class OrderItemExport
{
    public function store(): void
    {
        $rows = $this->query()->toBase()->cursor();

        foreach ($rows as $row) {
            $this->writer->addRow($this->map($row));
        }

        $this->writer->close();
    }

    private function map(object $row): array
    {
        $status = OrderItemStatusEnum::tryFrom($row->status_id);
        $currency = CurrencyEnum::tryFrom($row->currency_id);

        return [
            $row->order_id,
            $status?->label(),
            $currency?->code(),
        ];
    }
}

Enums are an easy target. They look like objects, they have methods, and you call them on every row. So the question came up naturally: do PHP enums create overhead in a loop like this?

$orderItemStatus = OrderItemStatusEnum::tryFrom($row->status_id);
$statusLabel = $orderItemStatus?->label();

Let's find out.

Enums in PHP are singletons

PHP 8.1 enums are objects - but each case is implemented as a singleton. Each enum case is instantiated once and reused for the lifetime of the request. That means:

$a = OrderItemStatusEnum::tryFrom(7);
$b = OrderItemStatusEnum::tryFrom(7);

$a === $b; // true

Same instance, every time. No new allocations, no garbage to collect.

The optimization experiment

To be sure, I refactored the export to use pre-cached arrays instead of calling tryFrom() on every row:

// Constructor
$this->statusLabels = OrderItemStatusEnum::labels();
$this->currencyNames = CurrencyEnum::names();

// Per row only array lookup
$this->statusLabels[$rowOrderItem->status_id] ?? null,

Also moved JSON localization to a raw SQL expression, so PHP doesn't decode JSON on every row:

->selectRaw("order_items.name->>'$.$locale' as localized_name")

Then I ran both versions against 50_000 rows with proper memory and GC profiling.

The results

Metric	Before	After
Time elapsed	4281 ms	4265 ms
Rows/sec	11,679	11,723
Memory used	8.5 MB	8.5 MB
GC runs	0	0
Objects collected	0	0

Nothing changed. Literally.
That's a 0.37% difference is just statistically irrelevant in real-world workloads.

What does this tell us?

GC never triggered because enum cases are persistent singletons and do not create cyclic references or short-lived heap allocations. Memory stayed flat because singletons don't accumulate. The 16ms diffrence is just noise. The real bottleneck in large exports is writing, I/O, and data formatting, not enum resolution.

Practical things

Use tryFrom() when you need clean, readable code. It's safe.
Pre-cache labels as arrays if you access them thousands of times, not for memory, but for micro-call overhead.
Don't profile enums through gc_status() - GC won't see them. Use Xdebug, Blackfire, php-meminfo for real memory/time analysis.
Enums are a feature for safety and readability, not a performance risk.

The optimization was real. The improvement... wasn't. And that's actually a good result: it means your enums are fine.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Why I Avoid PHP Traits (And What I Use Instead)

Ivan Mykhavko — Mon, 02 Feb 2026 13:21:44 +0000

PHP traits are usually presented as a handy way to reuse code. In practice, they are one of the most tricky tools in PHP and they can easily break your architecture, your tests, and your code readability.

I'm not saying traits are absolute evil. But after years of working with PHP, I kept coming to the same conclusion: traits are a design smell.

What Traits Actually Are

Traits appeared as a compromise to work around single inheritance. They are not inheritance, not composition, and not an interface. In short, it's a way to "glue" code into a class without explicit dependencies. And that's exactly where the problems start. On the low level, it works like simple copy-paste.

Why They Cause Problems

Poor readability. When I see a class with use SomeTrait, I don't know what that class actually does. To understand it, I need to open the trait, check what protected methods and properties it expects, and figure out if it overrides something. The behavior of the class becomes non-obvious.

Hidden coupling. In real code, traits almost always use protected properties of the class or call protected methods that the class doesn't implement itself. The result is two-way, implicit coupling - the trait knows about the class internals, and the class depends on the trait internals. You can't see this from the constructor or method signatures.

Broken encapsulation. Traits encourage access to the internal state of a class. Instead of clear contracts and explicit dependencies, you get: "the trait expects that somewhere there is a $service". Change the internal structure and the trait breaks.

Hard to test. You can't instantiate a trait. To test it, you need to create a fake class, set up all protected dependencies, and hope you didn't miss anything. That's not a unit test, it's a workaround.

Architectural chaos. PHP allows traits inside traits, multiple traits in one class. This makes it very easy to end up with diamond problems, dependency chains, and code that "works" but nobody understands how.

What About PHP 8.x Improvements?

PHP 8 added abstract methods, constants, and changes to static properties in traits. Unfortunately, from a SOLID and clean architecture point of view, this made things worse - traits now pull even deeper into inheritance thinking and static state.

The Typical Smell

If a trait has protected methods and uses protected services from the class, it almost always means there is a missing separate object that should be extracted into its own class.

What I Use Instead

In 90% of cases, the answer is simple:

Dependency Injection - dependencies are explicit, code is readable from the constructor
Composition - "has-a" instead of "uses"
Strategy / Factory - especially instead of protected helper methods
A simple class or function - if the trait has no state, it's probably not needed

All of these make dependencies visible, improve testability, and keep the architecture clean.

Quick Refactor Example

Before (with trait):

trait NotifiableTrait
{
    protected function notifyUser(string $message)
    {
        $this->notificationService->send($this->user, $message);
    }
}

final class OrderCreateAction
{
    use NotifiableTrait;

    public function handle(OrderCreateDTO $dto)
    {
        ...order logic...

        $this->notifyUser('Order created!'); // where is this from?
    }
}

After (with DI):

final class OrderCreateAction
{    
    public function __construct(private readonly UserNotifier $notifier) {}

    public function handle(OrderCreateDTO $dto)
    {
        ...order logic...

        $this->notifier->send($user, 'Order created!'); // explicit and clear
    }
}

Now dependencies are visible, testable, and explicit.

Conclusion

Traits are a shortcut that often leads to a long refactor later. If behavior can be extracted into a separate object, it should be extracted. If a trait has no state, it probably doesn't need to exist. I don't forbid traits. I just try not to pay for them later.

References

Doğan Uçar - PHP Traits 8.3: New Features But Still a Bad Concept
Barry O'Sullivan - Why I don't like traits

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Why Laravel Can't Guess Your Factory Relationships

Ivan Mykhavko — Tue, 13 Jan 2026 18:43:29 +0000

Laravel factories make testing a breeze, especially when you've got models that connect to each other. But sometimes, they'll trip you up in ways that aren't obvious at first. Joel Clermont made a great video about this, and I wanted to share my own take.

The Problem

Picture this: you've got a Client model, and it has two relationships to the same User model.

final class Client extends Model
{
    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }

    public function distributor(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }
}

Now you're writing a test:

$owner = UserFactory::new()->create(['name' => 'Owner']);
$distributor = UserFactory::new()->create(['name' => 'Distributor']);

$client = ClientFactory::new()
    ->for($owner)
    ->for($distributor)
    ->create();

What happens? Laravel sets user_id to the distributor's id, not the owner's. The distributor_id stays null. Not what you wanted.

Why This Happens

Laravel isn't broken, it's just sticking to its rules.

When you call for($model), Laravel looks at the model type, not your variable name. Both $owner and $distributor are User models. Laravel can't read your mind, so it just grabs the first relationship to User it finds, which is user. The variable names don't matter.

The Solution

Be explicit, tell laravel which relationship to use:

$client = ClientFactory::new()
    ->for($owner, 'user')
    ->for($distributor, 'distributor')
    ->create();

Now it works perfectly. The second argument is just the relationship name as a string.

Alternative: skip for

Sometimes being direct is clearer:

$client = ClientFactory::new()->create([
    'user_id' => $owner->id,
    'distributor_id' => $distributor->id,
]);

Nothing wrong here. Honestly, it's often clearer than stacking a bunch of for() calls.

When Conventions Break Down

Here's the thing: Laravel works best when you follow conventions. A Client with a user relationship? Perfect. But when you add a second relationship to the same model without a clear semantic difference, you're bending the rules a bit. From a pure Laravel-domain perspective, this might even suggest introducing a separate Distributor model. That doesn't mean it's wrong, sometimes you genuinely need multiple relationships to the same model.
So being explicit about relationship names keeps everything clear.

I checked my current project, and there are not many cases where for() is used with an explicit relationship name.
Just found this one:

$address = AddressFactory::new()
    ->for($user)
    ->has(DirectionFactory::new()
        ->has(DirectionScheduleFactory::new()->count(10), 'schedules'))
    ->create();

Naming matters

Some naming improvements can also reduce confusion:

Client → Customer
user → owner

When your relationship is called user but your domain talks about "owners," you're creating unnecesary mental overhead. Clearer names = fewer surprises.

Conclusion

Factories are powerful, but they rely on conventions. When your model design moves away from those conventions, explicitness beats magic:

Pass the relationship name to for(), or
Set the foreign keys yourself.

Laravel is doing exactly what it should. The responsibility is on us to be clear about our intent.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Thanks to Joel Clermont for the original video that inspired this post. His Laravel tips are always worth checking out.

Stop Flaky Tests: Freeze Time in Laravel Testing

Ivan Mykhavko — Fri, 09 Jan 2026 18:34:23 +0000

About a year ago, I wrote about freezing time when testing Laravel's temporary storage URLs.

Ivan Mykhavko

Jan 28 '25

Freezing Time: Testing Laravel Temporary Storage URLs

#laravel #testing #php #webdev

Comments

3 min read

Guess what? I ran into the same problem again, just from a different angle. It was a good reminder: controlling time in your tests isn't just a nice-to-have, it's essential.

The Problem

I had this test running smoothly on my machine. But then, on CI, it failed randomly:

public function test_order_item_cancel(): void
{
    $user = UserFixture::createUser();
    $this->actingAsFrontendUser($user);

    $order = OrderFixture::create($user);
    $orderItem = OrderItemFactory::new()->for($order)->for($user)->create();

    $response = $this->put(route('api-v2:order.order-items.cancel', ['uuid' => $orderItem->uuid]));

    $response->assertNoContent();

    $this->assertDatabaseHas(OrderItem::class, [
        'uuid' => $orderItem->uuid,
        'canceled_at' => Date::now(),
    ]);
}

Sometimes I'd get this error:

Failed asserting that a row in the table [order_items] matches the attributes {
    "canceled_at": "2026-01-09T10:24:52.008406Z"
}.

Found: [
    {
        "canceled_at": "2026-01-09 12:24:51"
    }
].

At first, I just shrugged and hit retry, like everyone does, right? 😅 But after reading The Flaky Test Chronicles VI, I realized I needed to actually pay attention. Was this a real bug, or just a flaky test?

Why This Happens

The problem's pretty simple: Date::now() gets called twice, but not at the same time.

First, when the controller sets canceled_at.
Then, again when the test checks the value.

Even a tiny delay, maybe just a millisecond, can make those two timestamps different. And CI is usually slower, so it happens more often there.

The Fix

Just freeze time before you make the request:


// Option 1
$this->freezeTime();
// Option 2
$now = Date::now();
Date::setTestNow($now);

$response = $this->put(route('api-v2:order.order-items.cancel', ['uuid' => $orderItem->uuid]));

$this->assertDatabaseHas(OrderItem::class, [
    'uuid' => $orderItem->uuid,
    'canceled_at' => $now,
]);

$this->freezeTime() is just a convenient wrapper around Date::setTestNow(), scoped to the test lifecycle.

Now both the controller and the test share the exact same timestamp. No more missmatches.

Another Way

If you don't care about the exact timestamp and just want to make sure the field isn't empty, go with this:


$this->assertDatabaseMissing(OrderItem::class, [
    'uuid' => $orderItem->uuid,
    'canceled_at' => null,
]);

Final thoughts

If your tests depend on time, take control of it. When test passes locally but fails in CI, freeze time using Date::setTestNow() or $this->freezeTime(). Make your tests reliable by controlling what you're testing. Build it right. Keep it deterministic. Trust your tests.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

whereHas() vs whereRelation(): Readability Over Shortcuts

Ivan Mykhavko — Mon, 05 Jan 2026 17:12:20 +0000

Laravel devs love their shortcuts. Tighter syntax, less boilerplate it's satisfying to trim down a few lines. But let's be honest: just because code is shorter doesn't mean it's better. When you're working with a team and the specs are always shifting, clear code always wins.

I recently came across Laravel tip suggesting we should replace whereHas() with whereRelation() for cleaner code. The example went like this:

// BEFORE
$users = User::whereHas('profile', function ($query) {
    $query->where('is_verified', false);
})->get();

// AFTER
$users = User::whereRelation('profile', 'is_verified', false)->get();

You can check the original post if you want the full breakdown.

Alright, here's where I land on this advice.

The tip isn't wrong, but presenting whereRelation() as a better alternative is misleading. It's just syntactic sugar. And honestly, in a real project, that surface-level "cleanliness" can backfire.

The Real Problem: Readability and Intent

Here's what I actually use in production:

$users = User::query()
    ->whereHas('profile', fn(Builder $query) => $query->where('is_verified', false))
    ->get();

Why is this better? Because it communicates intent clearly.

When you see whereHas(), you immediately understand:

Relationship is being filtered
Logic lives inside that relationship scope
More conditions can be added naturally

Note: I'm using arrow functions here for conciseness, but that's a separate improvement, you could use them with either method. The key distinction is the method itself.

Where whereRelation() Falls Short

The problem with whereRelation() is that it obscures what's actually happening. It looks like a simple column filter, but under the hood it's executing a subquery against a related table.

->whereRelation('profile', 'is_verified', false)->get();

This reads like filtering a direct column on users, not constraining a relationship. That's misleading.

And if you need more than one condition? With whereHas(), you just add them:

->whereHas('profile', fn(Builder $query) => $query
    ->where('is_verified', false)
    ->whereNotNull('phone')
    ->where('age', '>', 18)
)

With whereRelation(), this becomes awkward or impossible. You'd need multiple chained calls or give up and switch back to whereHas() anyway.

When whereRelation() Is Actually Fine

I'm not totally against whereRelation(). It works fine for stuff like:

Quick admin reports
Throwaway scripts
Tiny filters that'll never get more complex

For example:

User::query()->whereRelation('profile', 'is_verified', true)->count();

That's simple enough. But as soon as your logic gets even a little more complicated, just reach for whereHas(). It's clearer and won't confuse your future self or your teammates.

Performance Question

A lot of devs steer clear of whereHas() because someone told them it's slow. That's a different discussion entirely and usually the problem is missing indexes, or it's time to go with the query builder.
If you're filtering on profiles.is_verified and don't have an index, both whereHas() and whereRelation() will be slow, they generate nearly identical SQL.

But here's a practical issue: imagine you join a new project and get a ticket saying "the users endpoint is slow." What's your move? Search the codebase for relationship queries and check if proper indexes exist.

So you search for whereHas... and find nothing. Turns out the last dev used whereRelation() everywhere. Now you're hunting through method calls that don't look like relation filters at all. whereHas() is greppable and obvious. whereRelation() hides in plain sight.

The Consistency Problem

Here's what actually happens in real codebases:

You start simple. Maybe you reach for whereRelation():

User::query()->whereRelation('profile', 'is_verified', true)->get();

But business logic always changes. Suddenly you need second condition, so you switch to whereHas():

User::query()->whereHas('profile', fn(Builder $query) => $query
    ->where('is_verified', true)
    ->whereNotNull('phone')
)->get();

Now your codebase has both patterns. New folks don't know which one to use. Code reviews become inconsistent. You see whereRelation() in one file, whereHas() in another, and there's no real reason for it. Teams should agree on one default and deviate only with a reason.

If you just used whereHas() from the day one, this never happens. One style, consistent everywhere, and your code is ready when requirements get more complicated.

Laravel Internals: No Magic Here

Let's be real, whereRelation() is just a wrapper around whereHas(). It's not smarter, cleaner, efficent, or faster. It only saves you from writing a closure. If you don't believe me, check out the source code.

That's fine for trivial cases. But for real world app, queries with multiple conditions, maintainability concerns, or any chance of future growth, choosing whereHas() isn't old-fashioned it's more honest about what your code does.

My Rule of Thumb

One condition, zero chance it grows, quick script? Go with whereRelation().
Anything that matters: business logic, team projects, code you'll revisit use whereHas().

Don't try to save a few keystrokes. Write for the next developer (or yourself in six months) reading the code. whereRelation() is a nice shortcut, but don't mistake convenience for clarity. In most real scenarios, whereHas() with clean syntax wins for readability, scalability, and honest intent.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

PHP 8.5 Pipe Operator (|>) – Is It Worth Using?

Ivan Mykhavko — Mon, 22 Dec 2025 10:43:53 +0000

PHP 8.5 recently landed, so I wanted to try out some of the new stuff. Today I'm diving into the pipe operator (|>).

What's the Pipe Operator?

The pipe operator takes the return value from the left side and passes it to the right side, creating a left-to-right pipeline. Fans say it makes code easier to read and helps you follow the data as it moves along. Sounds cool, right? But does it actually help? Let's see.

I've seen many posts praising this as a game-changing feature. Honestly, my first thought was "Huh, that looks weird." I stayed skeptical. Instead of just going with my gut, I figured I'd throw it into some real code and see what happens.

If you want to dig deeper, check out PHP.Watch Documentation, The Official RFC, or Amit Merchant's examples.

Testing in Practice

Instead of just reading about it, I crafted some practical examples that represent actual production code. I ran benchmarks inside a Laravel 12 app with PHP 8.5. Full code of the command is on GitHub if you want to see everything. Here's what I tried:

1. User Input Sanitization

Traditional:

private function sanitizeEmailTraditional(string $email): string
{
    $cleaned = trim($email);
    $cleaned = strtolower($cleaned);
    $cleaned = filter_var($cleaned, FILTER_SANITIZE_EMAIL);

    return $cleaned;
}

With pipe:

private function sanitizeEmailPipe(string $email): string
{
    return $email
            |> trim(...)
            |> strtolower(...)
            |> (fn($e) => filter_var($e, FILTER_SANITIZE_EMAIL));
}

Honestly, this is a nice fit. Chaining a few simple functions with the pipe operator feels smooth and the code stays readable.

2. CSV Data Processing

Say you need to filter, calculate, sort, and format some CSV data.

Traditional:

private function processEmployeesTraditional(array $employees): array
{
    $engineering = array_filter(
        $employees,
        fn($emp) => $emp['department'] === 'Engineering'
    );

    $withBonus = array_map(function ($emp) {
        $emp['salary'] = (int) $emp['salary'];
        $emp['bonus'] = (int) ($emp['salary'] * 0.1);
        return $emp;
    }, $engineering);

    usort($withBonus, fn($a, $b) => $b['salary'] <=> $a['salary']);

    return array_map(
        fn($emp) => [
            'name' => $emp['name'],
            'total' => $emp['salary'] + $emp['bonus']
        ],
        $withBonus
    );
}

With pipe:

private function processEmployeesPipe(array $employees): array
{
    return $employees
            |> (fn($e) => array_filter($e, fn($emp) => $emp['department'] === 'Engineering'))
            |> (fn($e) => array_map(function ($emp) {
                $emp['salary'] = (int) $emp['salary'];
                $emp['bonus'] = (int) ($emp['salary'] * 0.1);
                return $emp;
            }, $e))
            |> (fn($e) => (function ($arr) {
                usort($arr, fn($a, $b) => $b['salary'] <=> $a['salary']);
                return $arr;
            })($e))
            |> (fn($e) => array_map(
                fn($emp) => [
                    'name' => $emp['name'],
                    'total' => $emp['salary'] + $emp['bonus']
                ], $e
            ));
}

Notice how we needed nested closures and an awkward wrapper just to handle usort. The "natural flow" actually gets messier here.

3. API Response Formatting

Turning raw data from a third-party api into something usable.

Traditional:

private function formatApiResponseTraditional(array $raw): array
{
    $metadata = json_decode($raw['metadata'], true);

    $formatted = [
        'userId' => $raw['user_id'],
        'userName' => $raw['user_name'],
        'createdAt' => $raw['created_at'],
    ];

    $formatted['createdAt'] = strtotime($formatted['createdAt']);
    $formatted['tags'] = explode(',', $raw['tags']);
    $formatted['settings'] = $metadata;

    return $formatted;
}

With pipe:

private function formatApiResponsePipe(array $raw): array
{
    return $raw
            |> (fn($data) => json_decode($data['metadata'], true))
            |> (fn($metadata) => [
                'userId' => $raw['user_id'],
                'userName' => $raw['user_name'],
                'createdAt' => $raw['created_at'],
                'tags' => $raw['tags'],
                'metadata' => $metadata,
            ])
            |> (fn($data) => [
                ...$data,
                'createdAt' => strtotime($data['createdAt']),
            ])
            |> (fn($data) => [
                ...$data,
                'tags' => explode(',', $data['tags']),
            ])
            |> (fn($data) => [
                'userId' => $data['userId'],
                'userName' => $data['userName'],
                'createdAt' => $data['createdAt'],
                'tags' => $data['tags'],
                'settings' => $data['metadata'],
            ]);
}

What could be a clear, single transformation gets split into five steps, each making a new array. Is this really easier to maintain? I don't think so. The traditional code shows exactly what's going on.

Performance Results

I ran each benchmark million times. Here's what happened:

User input sanitization:
Traditional: 0.000462 ms
Pipe:        0.000562 ms
Traditional is 21.55% faster

CSV data processing:
Traditional: 0.002088 ms
Pipe:        0.002702 ms
Traditional is 29.40% faster

API response formatting:
Traditional: 0.001432 ms
Pipe:        0.002064 ms
Traditional is 44.15% faster

Performance hit lands somewhere between 20% and 45%. In absolute terms, we're talking microseconds, so for most web requests, it won't matter. But the pipe operator adds overhead without bringing performance gains.

When Pipes Actually Shine

In some cases, pipes do work well:

// Simple, pure fn chains
return $price
    |> applyDiscount(...)
    |> addTax(...)
    |> formatCurrency(...);

// Clean str transformations
return $input
    |> trim(...)
    |> strtolower(...)
    |> ucfirst(...);

They're great for lining up a few pure functions, each step obvious and named. But the second you need to mutate data, deal with side effects, or handle functions that don't fit the pipeline pattern (like usort), the traditional way comes out ahead.

My Take

The pipe operator isn't the readability miracle people make it out to be. For short, pure chains, it's fine. But for real-world code with mutations or tricky logic, the traditional approach is clearer, easier to maintain, and actually faster.

Don't refactor working code just to use pipes. If your team isn't already comfortable with this functional style, adding pipes will probably confuse more than it helps.

The performance cost is tiny and won't matter for most apps. The real issue is readability in complex code, and that's where pipes stumble. After trying these examples, I won't be reaching for pipes in production. The old way works better for the kind of code I write.

Should You Use It?

If you love chaining pure functions and the left-to-right style clicks for you, go for it. But for more complicated stuff or if your team's not into functional programming just stick with what you know. It's easier to read, easier to maintain, and just makes more sense despite what the pipe advocates claim.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Merry Christmas and Happy New Year! Don't forget to upgrade to PHP 8.5 and explore the new features. 🎄

Don't Let Your Staging Server Die: Separate Task Scheduling in Laravel

Ivan Mykhavko — Sat, 29 Nov 2025 22:39:02 +0000

If you're running Laravel in production, you probably use task scheduling. It's one of those features that just works, until it stops. Especially on your staging server.

The Problem

If you're building real apps, you need a staging environment. It's your safe playground to test changes before they hit production.
I run a simple one on a Digital Ocean droplet just 2 vCPUs, nothing really fancy. It handles my Laravel 10 app like a champ... until one day, it didn't. The server just froze and wouldn't respond. I jumped in over SSH and popped open htop revealed both cpu cores maxed out and memory nearly full:

   1[||||||||||||||||||100.0%]   
   2[||||||||||||||||||100.0%]     
Mem[||||||||||||||| 3.2G/4.0G]

Brutal. Both CPUs totally pegged, memory barely hanging on at 3.2 out of 4 gigs. Definitely not what you want to see.

Why It Matters

The guilty party? A quick ps aux and scan logs pointed straight to the scheduler. Heavy scheduled commands that make sense in production but kill a smaller staging server: price exports every couple hours, supplier syncs with thousands of products, and crunching huge datasets for stats.

These tasks are necessary in production with proper resources. Staging just can't handle that load, and honestly, it doesn't even need most of those jobs running so often or at all.

The Solution

The fix is simple: separate your schedule() method based on environment. Don't run the same schedule everywhere.

I'm on Laravel 10, so I tweak the app/Console/Kernel.php. (Heads up: In Laravel 11+, shift to routes/console.php)

final class Kernel extends ConsoleKernel
{
    protected function schedule(Schedule $schedule): void
    {
        $this->scheduleCommon($schedule);

        if ($this->app->environment(AppEnvironmentEnum::PRODUCTION->value)) {
            $this->scheduleProduction($schedule);
        }

        if ($this->app->environment(AppEnvironmentEnum::STAGING->value)) {
            // Less frequent or reduced workload for staging
            $this->scheduleStaging($schedule);
        }
    }
}

How to Structure It

Common Schedule

Tasks that should run everywhere: cleanup, pruning, basic maintenance.

private function scheduleCommon(Schedule $schedule): void
{
    // Keep DB lean everywhere
    $schedule->command(PruneCommand::class, ['--model' => [CartItem::class]])->hourly();
    $schedule->command(PruneCommand::class, ['--model' => [OrderItemNotification::class]])->daily();

    // Clear expired tokens
    $schedule->command(PruneExpired::class)->dailyAt('03:00');

    // Basic notifications
    $schedule->command(TelegramNotificationSendCommand::class)->hourly()->withoutOverlapping();
    $schedule->command(UserSendConfirmationNotificationCommand::class)->hourly();
}

Production Schedule

Heavy operations that need frequent execution and have proper resources.

private function scheduleProduction(Schedule $schedule): void
{
    // Search index sync
    $schedule->command(SearchIndexSyncDiff::class)->dailyAt('05:00');

    // Auto price exports - multiple times per day
    $schedule->command(PriceExportAutoDispatchCommand::class)->cron('15 6,8,10,12,14,16,18 * * *');

    // Supplier sync - runs 7 times per day
    $schedule->command(TmSyncPriceExportProduct::class)->cron('1 6,8,10,12,14,16,18 * * *');

    // Product availability updates
    $schedule->command(ProductAvailabilityUpdateCommand::class)->hourlyAt(15)->between('08:00', '19:00');
}

Staging Schedule

Same commands, but less frequent. Only what you actually need for testing.

private function scheduleStaging(Schedule $schedule): void
{
    // Price exports - once per day is enough
    $schedule->command(PriceExportAutoDispatchCommand::class)->cron('15 6 * * *');

    // Supplier sync - once per day
    $schedule->command(TmSyncPriceExportProduct::class)->cron('1 6 * * *');

    // Test suspended orders more frequently for debugging
    $schedule->command(OrderProcessSuspendedCommand::class)->everyMinute()->between('08:00', '19:00')->withoutOverlapping();
}

The Results

Once I split up the workloads, my staging cores chilled under 20% and held steady at around 1.5GB. The server stayed responsive, and I can still run scheduled tasks whenever I need to. Production continued operating at full capacity without any impact.

Env	CPU Usage	Memory Usage
Staging (before)	100%	3.2G / 4G
Staging (after)	15-20%	1.5G / 4G

Conclusions

Separate task schedules by environment from day one, and let staging take it easy. Heavy jobs should run less often and keep only essential maintenance routines. Copying production schedules blindly to staging is a fast track to chaos. They usually have less CPU and memory anyway.

With these changes, staging CPU usage drops to 15-20%, tests run smoothly, and deployments feel confident. Production stays strong and untouched. This setup is easy for scales: just add environment checks for new commands.

Your staging environment should mirror production functionally, not identically. Adjust task frequencies to match your server resources. Your infrastructure will appreciate it.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

From 20 to 24 LTS: Safe Way to Upgrade Ubuntu on DigitalOcean

Ivan Mykhavko — Thu, 20 Nov 2025 21:36:58 +0000

Upgrading an old production server is not a popular topic today. Most run Docker, Kubernetes, or at least keep OS fresh. But sometimes you inherit a legacy VM, full of configs, and you just need to push it to a modern LTS without breaking anything.

I had exactly this case on DigitalOcean. Here's a quick, real-world rundown of what I actually did.

The Problem

The project was running on Ubuntu 20.04 with an outdated Nginx. Direct upgrade to 24.04 LTS is not possible. I needed a way to bring everything up-to-date quickly and safely and keep downtime to minimum.

Why It Matters

Those kinetic and lunar are eol versions. They no longer receive security updates. Running outdated versions exposes your server to vulnerabilities and leaves you without support. The jump to 24.04 LTS is significant - you get five years of support, better performance, and peace of mind.

How I Did It

To avoid downtime, I leaned on DigitalOcean snapshots + temp droplet. Then I upgraded the system in steps:

20.04 → 22.10 → 23.04 → 23.10 → 24.04 lts + Nginx upgrade

It's a bit long, but it gets the job done if you're stuck on an old upgrade path.

1. Prep the Server (No Downtime Yet)

First things first:

Take a snapshot of your existing droplet.
Use that snapshot to create a temporary droplet.
Set up Floating IP so you can point your domain to this temp droplet when it's ready.

This gives you a safe rollback if something goes wrong.

2. Do the Upgrades

Upgrade to Ubuntu 22.10

sudo sed -i 's|http://mirrors.digitalocean.com/ubuntu/|http://old-releases.ubuntu.com/ubuntu/|g' /etc/apt/sources.list && \
sudo sed -i 's|http://security.ubuntu.com/ubuntu|http://old-releases.ubuntu.com/ubuntu|g' /etc/apt/sources.list && \
sudo apt update && \
sudo apt upgrade -y && \
sudo apt dist-upgrade -y && \
sudo apt autoremove --purge -y && \
sudo apt install -y ubuntu-release-upgrader-core && \
sudo sed -i 's/kinetic/lunar/g' /etc/apt/sources.list && \
sudo apt update && \
sudo apt upgrade -y && \
sudo apt dist-upgrade -y && \
sudo apt full-upgrade -y && \
sudo apt autoremove --purge -y && \
echo -e "\nUpgrade complete! Rebooting now...\n" && \
sudo reboot

Upgrade 23.04 → 23.10

sudo sed -i 's|http://old-releases.ubuntu.com/ubuntu|http://old-releases.ubuntu.com/ubuntu|g' /etc/apt/sources.list && \
sudo sed -i 's/lunar/mantic/g' /etc/apt/sources.list && \
sudo apt update && \
sudo apt upgrade -y && \
sudo apt dist-upgrade -y && \
sudo apt full-upgrade -y && \
sudo apt autoremove --purge -y && \
echo -e "\nUpgrade complete! Rebooting now...\n" && \
sudo reboot

Upgrade 23.10 → 24.04 LTS

sudo sed -i 's|http://old-releases.ubuntu.com/ubuntu|http://archive.ubuntu.com/ubuntu|g' /etc/apt/sources.list && \
sudo sed -i 's/mantic/noble/g' /etc/apt/sources.list && \
sudo apt update && \
sudo apt upgrade -y && \
sudo apt dist-upgrade -y && \
sudo apt full-upgrade -y && \
sudo apt autoremove --purge -y && \
echo -e "\nUpgrade complete! Rebooting now...\n" && \
sudo reboot

Now you're on Ubuntu 24.04 LTS. Double-check with:

lsb_release -a

3. Upgrade to the Latest Nginx

Don't skip this backup step:

cp -r /etc/nginx /root/nginx-backup

Then install the latest Nginx package:

curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu noble nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx
nginx -v

You should see version ^1.28.0. Reload your configuration to make sure it still parses:

sudo nginx -t
sudo systemctl restart nginx

4. Point the Floating IP Back

Wait a few minutes. Check your app. Run your health checks, monitoring, whatever you've got. If you have automated tests, don't forget to run them.
Look at logs and metrics make sure it's all good. Everything working? Cool. Move to the next.

Once you're sure everything's stable, switch the Floating IP back from the temp droplet to your freshly upgraded one.

Hang on to the temp droplet and snapshot for few days. If nothing catches fire, you can remove them.

Timeline

Total time: about one hour. Most of that is just waiting for reboots and packages to download. You can grab coffee and check on progress every few minutes.

Final Thoughts

This isn't a workflow I want to repeat often. If you can move to Docker or rebuild your server from scratch — do it.

But sometimes legacy systems don't give you that choice.
And when you must upgrade an old Ubuntu machine step by step, this method works. Fast, safe, and almost zero downtime.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Laravel Validation after() - After What, Exactly?

Ivan Mykhavko — Mon, 03 Nov 2025 11:04:52 +0000

If you've worked with Laravel's Form Requests, you've probably run into the after() method for custom validation. But it works slightly differently that it named.

Common Misconception

When you see a method called after(), you'd figure it runs after all the regular validation passes. That's what I assumed, too. Makes sense, doesn't it? But that's not how it works.

Real Example

Let me show you what I mean with a real example. Here's how you might set up validation rules for storing related articles in catalog:

public function rules(): array
{
    return [
        'article' => ['required', ...DetailArticleRule::rules()],
        'brand_id' => ['required', 'integer', 'min:1'],
        'related_article' => ['required', ...DetailArticleRule::rules(), 'different:article'],
    ];
}

public function after(): array
{
    return [
        function (Validator $validator): void {
            $brandId = $this->integer('brand_id');

            $existsMain = Product::query()
                ->where('article', $this->string('article')->toString())
                ->where('brand_id', $brandId)
                ->exists();

            if (!$existsMain) {
                $validator->errors()->add('article', __('validation.exists'));
            }
            // ... more checks
        },
    ];
}

At first glance, this makes sense. You do your usual validation, then use after() to tack on extra database checks.

The Problem

Ok, try sending "bad" request:

{
  "article": "P900RM11",
  "brand_id": "Hepu",
  "related_article": "P900RM11005"
}

You get a nice error response about invalid brand_id (it's string, not int) and bad articles.
But take a look at your database logs:

select exists(select * from `products` where `article` = 'P900RM11005'...) 
select exists(select * from `products` where `article` = 'P900RM11'...)

Wait a second, validation failed, but you're still hitting the database. Not cool.

And it gets messier. What if someone sends this?

{
  "article": "P900RM11",
  "brand_id": 5,
  "related_article": ["P900RM11005"]
}

Now you get an "Array to string conversion" exception. The after() callback tries to process invalid types, falls over, and you end up with a 500 error instead of a helpful validation message.

What Laravel Docs Actually Say

From the off docs:

The after method accepts a closure or an array of callables which will be invoked after validation is complete.

The important bit is "after validation is complete" - not "after validation passes." That means after() runs even when validation fails. Yeah, the name is misleading.

The Quick Fix

So, if you're using after(), you need to guard yourself:

public function after(): array
{
    return [
        function (Validator $validator): void {
            if ($validator->errors()->isNotEmpty()) {
                return; // Stop if basic validation failed
            }
            // Now it's safe to do DB checks
        },
    ];
}

This way, you avoid unnecessary queries and weird crashes.

The Better Solution

But here's the bigger point: database queries don't belong in HTTP validation. Validation should be fast and stateless. Its job is to check the shape of the data and basic rules-nothing that requires hitting the database.

Mixing in database calls here slows things down, couples your HTTP layer to your persistence layer, and makes testing a pain. Plus, you burn resources on requests that weren't valid from the start.

The better approach? Move this stuff into a service layer:

// In RelatedArticleService
public function createEdge(string $article, int $brandId, string $relatedArticle, int $relatedBrandId): void
{
    $this->validateEdge($article, $brandId, $relatedArticle, $relatedBrandId);

    $this->repository->insertEdge($article, $brandId, $relatedArticle, $relatedBrandId);

    // more business logic...
}

private function validateEdge(string $article, int $brandId, string $relatedArticle, int $relatedBrandId): void
{
    $existsMain = Product::query()
        ->where('article', $article)
        ->where('brand_id', $brandId)
        ->exists();

    if (!$existsMain) {
        throw ValidationException::withMessages([
            'article' => __('validation.exists', ['attribute' => 'article'])
        ]);
    }

     // other checks...
}

Now, your Form Request just handles HTTP validation, and your service takes care of all the business logic and any domain-specific checks.

Final Thoughts

So, to sum it all up: Laravel's after() method can be useful, but keep these things in mind

It runs no matter what - even if the main validation failed.
If you want conditional logic, you'll need to check for errors yourself.
Heavy operations (like database queries) belong in your service layer, not Form Requests.

That's really the best way to keep your code fast, clean, and easy to test.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Battling Laravel's Sneaky DELETEs: How I Got ORDER BY and LIMIT to Play Nice with Joins

Ivan Mykhavko — Sun, 12 Oct 2025 18:17:41 +0000

Hey folks, if you've ever stared at your terminal in horror as Laravel cheerfully deletes half a million rows instead of the tidy batch of 500 you asked for, you're not alone. That's exactly what kicked me into gear a few weeks back. As a Laravel enthusiast, I dove into the framework's MySQL grammar to sort out this quirky behavior. Spoiler: it ended in a merged PR and a few lessons in database drama. Let's break it down.

The Sneaky Problem

Picture this: You're cleaning up a massive cross_product_references table by joining it with products and nuking invalid entries in chunks. Your code looks solid-LIMIT(500), ORDER BY id, and a tidy while loop to keep things batched. But nope. Laravel's MySQL grammar? It silently strips the ORDER BY and LIMIT when JOINs are in the mix. Boom: one query, all 500k+ rows gone. Poof.

Here's the culprit in action (straight from my console command):

$batchSize = 500;
$totalDeleted = 0;

do {
    $deleted = DB::table('cross_product_references as cpr')
        ->leftJoin('products as p1', fn($join) => $join
            ->on('cpr.article', '=', 'p1.article')
            ->on('cpr.brand_id', '=', 'p1.brand_id'))
        ->leftJoin('products as p2', fn($join) => $join
            ->on('cpr.cross_article', '=', 'p2.article')
            ->on('cpr.cross_brand_id', '=', 'p2.brand_id'))
        ->where(fn($query) => $query
            ->whereNull('p1.id')
            ->orWhereNull('p2.id'))
        ->limit($batchSize)
        ->orderBy('cpr.id')
        ->delete();
    $totalDeleted += $deleted;
} while ($deleted > 0);

$this->line("Deleted <info>$totalDeleted</info> rows.");

Expected: Batches of 500, safe and sound. Actual: one massive, spectacular (and slightly horrifying) purge.
Turns out, this "feature" was there to dodge MySQL's native gripes about ORDER BY/LIMIT in DELETE...JOIN queries. But silent failures? Not cool.

The Fix (and a Side of Debate)

I fired up a PR #57138 overriding compileDeleteWithJoins in MySqlGrammar. Now? Laravel spits out the full SQL-JOINs, ORDER BY, LIMIT and all. Let the database (MySQL, MariaDB, or even Vitess) decide if it's happy. On vanilla MySQL? You'll get a crisp QueryException. Check mysql docs for more info (Mysql: Multi-Table Deletes). On PlanetScale or Vitess? It just works, thanks to their query-rewriting magic.

But oh, the comments! Taylor Otwell and Graham Campbell chimed in, and we had a mini philosophy sesh: Throw a framework exception for safety, or let MySQL yell? I pushed for explicit errors to avoid "surprise deletions," but we landed on compiling the full query anyway-best of both worlds. A quick branch swap to target master, some test tweaks, and... PR #57196 was born. Fast-forward a few days, and yeah, it got merged. 🎉

So, why does this actually matter? Predictability, my friend. You don't want your maintenance scripts nuking the database behind your back. If you're batch-deleting with joins, jump on the latest Laravel and double-check those LIMITs. Old-school MySQL folks, here's a hack: snag the IDs with FOR UPDATE, then do your DELETE WHERE IN. Works like a charm.

TL;DR

Laravel now respects ORDER BY and LIMIT in DELETE ... JOIN queries for MySQL. If the DB doesn't support it - you'll get a proper exception instead of a silent data wipe.

💡 PRs in question: #57138 (draft) and #57196

🚀 Merged into: Laravel 13.x

Grateful for the Laravel crew's sharp eyes-it was a reminder that open-source magic happens in those comment threads. Got a similar gotcha? Hit reply or ping me @tegos. What's your wildest query story?

Laravel Cache Tip: Avoid Redundant has/missing Calls

Ivan Mykhavko — Wed, 03 Sep 2025 12:14:03 +0000

When working with Laravel's cache, I often see developers using a pattern that, while functional, creates unnecessary overhead. Let me show you a simple optimization that can improve both performance and memory usage.

The Common Pattern (With Redundancy)

Here's a typical cache implementation I see frequently:

public function getUserCount(): int
{
    $cacheKey = 'user-count';
    $cacheTtl = Carbon::now()->addMinutes(10);

    // Bad: two cache ops
    if (Cache::has($cacheKey)) {
        return (int) Cache::get($cacheKey);
    }

    $userCount = User::query()->count();
    Cache::put($cacheKey, $userCount, $cacheTtl);

    return $userCount;
}

This works perfectly, but there's a subtle inefficiency: the cache is accessed twice when the key exists.
Looking at Laravel Telescope, you'll see:

Action | Key
hit    | user-count  (line 31)
hit    | user-count  (line 32)

The Better Approach: Skip `has()`

Instead of checking if the key exists first, we can directly attempt to retrieve it:

public function getUserCountOptimized(): int
{
    $cacheKey = 'user-count';
    $cacheTtl = Carbon::now()->addMinutes(10);

    // Good: only one cache op
    $cachedValue = Cache::get($cacheKey);

    if ($cachedValue !== null) {
        return (int) $cachedValue;
    }

    $userCount = User::query()->count();
    Cache::put($cacheKey, $userCount, $cacheTtl);

    return $userCount;
}

Or just use Laravel's remember() method, which combines the check and retrieval into a single operation:

public function getUserCountRemember(): int
{
    $cacheKey = 'user-count';
    $cacheTtl = Carbon::now()->addMinutes(10);

    return Cache::remember($cacheKey, $cacheTtl, function () {
        return User::query()->count();
    });
}

This results in only one cache hit, reducing overhead:

Action | Key
hit    | user-count  (line 31)

When `remember()` Isn't Enough

So, yeah - Cache::remember() is fine if you're just dealing with basic stuff. However, remember() isn't always practical. For complex scenarios, like caching third-party API responses with conditional logic, remember() may not fit. Here's a real-world example from a third-party API integration that needed extra hoops:

/**
 * Flow: from cache → try HTTP → handle response → cache it
 */
private function performRequest(string $endpoint, array $data = []): array
{
    $cacheKeyParams = ['endpoint' => $endpoint, ...$data];
    $cacheTags = [CacheKeyEnum::TM->tag()];

    if (isset($cacheKeyParams['code'])) {
        $cacheTags[] = CacheKeyEnum::SEARCH_ARTICLE->tag([$cacheKeyParams['code']]);
    }

    $cacheKey = CacheKeyEnum::TM->key($cacheKeyParams);
    $cacheTtl = TmApiEndpointEnum::getCacheTtl($endpoint);

    // Return the cached result first if caching is enabled
    if ($this->cacheEnabled) {
        if (Cache::tags($cacheTags)->has($cacheKey)) {
            $responseData = Cache::tags($cacheTags)->get($cacheKey);
            if ($responseData !== null) {
                return $responseData;
            }
        }
    }

    // Make API call
    try {
        $response = $this->getClient()->post($endpoint, $data)->throw();

        $responseData = $this->responseHandler($response);

        if (!empty($responseData)) {
            Cache::tags($cacheTags)->put($cacheKey, $responseData, $cacheTtl);
        }

        return $responseData;
    } catch (Throwable $exception) {
        return $this->handleException($exception, $endpoint, $data);
    }
}

This method handles monster-sized API responses (e.g., 1MB JSON) and logs two cache hits:

hit: tm|endpoint=pricesearch|... (line 114)
hit: tm|endpoint=pricesearch|... (line 115)

You can optimize it by removing the has check:

if ($this->cacheEnabled) {
    $responseData = Cache::tags($cacheTags)->get($cacheKey);
    if ($responseData !== null) {
        return $responseData;
    }
}

So, How Much Faster?

I actually ran the numbers. With huge api responses:

Before (with has()):

About 14ms per execution
47MB memory
2 cache operations

After (without has()):

Around 6ms
43MB
Only 1 cache op

Pattern	Time	Memory	Cache Ops
With `has()`	14ms	47MB	2
Without	6ms	43MB	1

Both are snappy, but hey, that's almost double the speed and less memory. The optimized version shows measurable improvements in both execution time and memory usage.

What's the Point?

Avoid unnecessary Cache::has() or Cache::missing() calls when you immediately follow them with Cache::get(). Each cache operation has overhead, and eliminating redundant calls improves performance, especially when dealing with large cached values.

The pattern is simple:

Try to get the value directly
Check if it's null
Proceed accordingly

It's a tiny change, but when multiplied across thousands of requests, the difference is real. One less cache call per request means faster responses and lower memory usage - for free.

Ever run into cache weirdness or found other sneaky optimizations in Laravel? Drop your stories below.

Forem: Ivan Mykhavko

$fillable Has No Context: Why Mass Assignment Breaks Down at Scale

The Usual Approach

What Goes Wrong in Practice

You lose visibility fast

The real problem: $fillable has no context

What I Use Instead

The "Just Disable It" Way

The Point

TL;DR

Author's Note

PHP Enums Are Not Your Bottleneck (Here's Proof)

Enums in PHP are singletons

The optimization experiment

The results

What does this tell us?

Practical things

Author's Note

Why I Avoid PHP Traits (And What I Use Instead)

What Traits Actually Are

Why They Cause Problems

What About PHP 8.x Improvements?

The Typical Smell

What I Use Instead

Quick Refactor Example

Conclusion

References

Author's Note

Why Laravel Can't Guess Your Factory Relationships

The Problem

Why This Happens

The Solution

Alternative: skip for

When Conventions Break Down

Naming matters

Conclusion

Author's Note

Stop Flaky Tests: Freeze Time in Laravel Testing

Freezing Time: Testing Laravel Temporary Storage URLs

The Problem

Why This Happens

The Fix

Another Way

Final thoughts

Author's Note

whereHas() vs whereRelation(): Readability Over Shortcuts

The Real Problem: Readability and Intent

Where whereRelation() Falls Short

When whereRelation() Is Actually Fine

Performance Question

The Consistency Problem

Laravel Internals: No Magic Here

My Rule of Thumb

Author's Note

PHP 8.5 Pipe Operator (|>) – Is It Worth Using?

What's the Pipe Operator?

Testing in Practice

1. User Input Sanitization

2. CSV Data Processing

3. API Response Formatting

Performance Results

When Pipes Actually Shine

My Take

Should You Use It?

Author's Note

Don't Let Your Staging Server Die: Separate Task Scheduling in Laravel

The Problem

Why It Matters

The Solution

How to Structure It

Common Schedule

Production Schedule

Staging Schedule

The Results

Conclusions

Author's Note

From 20 to 24 LTS: Safe Way to Upgrade Ubuntu on DigitalOcean

The Problem

Why It Matters

How I Did It

The real problem: `$fillable` has no context

The Better Approach: Skip `has()`

When `remember()` Isn't Enough