Forem: Ash Allen

Measuring Performance with the "Benchmark" Class in Laravel

Ash Allen — Fri, 23 Jan 2026 00:00:00 +0000

Introduction

When building Laravel applications, I often need to measure the execution time of different code blocks. This could be when I'm experimenting with different approaches to solving a problem or optimising existing code.

Although there are dedicated profiling and performance-monitoring tools available, I sometimes just need a rough idea of performance rather than a detailed analysis. This is where the Illuminate\Support\Benchmark class comes in handy.

The Benchmark class provides multiple simple ways to measure the execution time of a piece of code.

In this article, we'll take a look at how to use the Benchmark class in Laravel to measure the performance of different code blocks, along with some important considerations to keep in mind when using it.

Using the `Benchmark` class

As I mentioned, I use the Benchmark class quite often when building new features and experimenting with different approaches to solving a problem. Sometimes I have an idea of how I'm going to implement a feature, but I'm not sure it will be efficient enough. So in this scenario, I might try out a couple of different implementations and use the Benchmark class to measure their execution times. This then allows me to make a more informed decision about which approach to use based on real numbers rather than just a hunch.

Sometimes, the results show that the differences between implementations are negligible and unlikely to have a significant impact on overall performance. Other times, the results can be quite surprising, revealing that one approach is significantly faster than another. In these cases, using the Benchmark class can be incredibly useful for identifying potential bottlenecks before they become a problem in production.

You can interact with the Benchmark class in three different ways:

Benchmark::measure() - Measures the execution time and returns it as a float value (in milliseconds).
Benchmark::value() - Measures the execution time and returns both the result of the code and the execution time as a float value (in milliseconds).
Benchmark::dd() - Measures the execution time and dumps it using dd() as a formatted string (in milliseconds).

Let's take a look at each of these methods. We'll stick to simple examples (inspired by those in the Laravel documentation) that work really well for demonstrating the Illuminate\Support\Benchmark class.

Using "Benchmark::measure()"

The Benchmark::measure() method accepts a closure (or an array of closures, which we'll get to later) and returns the execution time as a float value (in milliseconds).

For example:

use App\Models\User;
use Illuminate\Support\Benchmark;

$executionTime = Benchmark::measure(fn () => User::find(1));

// $executionTime will be: 0.271625

// This means the code took approximately 0.27 milliseconds to execute.

It also accepts a second argument, iterations, which specifies how many times to run the benchmarked code. The returned value will be the average execution time across all iterations, which is really useful for getting a more accurate measurement, since individual runs can be affected by factors like CPU load and memory usage.

You can specify the number of iterations like this:

use App\Models\User;
use Illuminate\Support\Benchmark;

$executionTime = Benchmark::measure(
    benchmarkables: fn () => User::find(1),
    iterations: 10,
);

// $executionTime will be: 0.271625

// This means the code took approximately 0.27 milliseconds to execute on average.

You can also pass an array of closures to benchmark multiple pieces of code in one go. This is really handy for comparing the performance of different implementations side by side. For example:

use App\Models\User;
use Illuminate\Support\Benchmark;

$executionTime = Benchmark::measure(
    benchmarkables: [
        fn () => User::count(),
        fn () => User::all()->count(),
    ],
    iterations: 10,
);

// $executionTime will be: [0.5, 20.0]

// This means the first closure took approximately 0.5 milliseconds to execute,
// and the second closure took approximately 20.0 milliseconds to execute.

Using "Benchmark::value()"

The Benchmark::value() method is similar to Benchmark::measure(), but it also returns the benchmarked code's result along with the execution time.

It accepts a closure and returns an array containing two elements:

The return value of the closure.
The execution time as a float value (in milliseconds).

Here's an example:

use App\Models\User;
use Illuminate\Support\Benchmark;

[$user, $executionTime] = Benchmark::value(fn () => User::find(1));

// $user will be the App\Models\User model with ID 1.
// $executionTime will be: 0.271625
// This means the code took approximately 0.27 milliseconds to execute.

Unlike the Benchmark::measure() and Benchmark::dd() methods, Benchmark::value() does not support passing an array of closures or running multiple iterations. It's designed to measure a single piece of code and return its result along with the execution time. So this is a great option when you want to measure the performance of a specific operation and also use its result in your code without disrupting the flow.

Using "Benchmark::dd()"

The Benchmark::dd() method is a quick and easy way to measure the execution time of a piece of code and dump the result using Laravel's dd() function.

It works in pretty much the same way as the Benchmark::measure() method, but instead of returning the execution time, it dumps it directly to the screen.

It's important to note that this method returns the execution time as a formatted string (in milliseconds) rather than a raw float value; for example, "0.270ms" rather than 0.270625.

Let's look at an example of how to use it:

use App\Models\User;
use Illuminate\Support\Benchmark;

Benchmark::dd(fn () => User::find(1));

// The following will be dumped: "0.270ms"

Similar to the Benchmark::measure() method, you can also specify the number of iterations to run the benchmarked code, and the average execution time will be returned:

use App\Models\User;
use Illuminate\Support\Benchmark;

Benchmark::dd(
    benchmarkables: fn () => User::find(1),
    iterations: 10,
);

// The following will be dumped: "0.270ms"

You can also pass an array of closures to benchmark multiple pieces of code in one go:

use App\Models\User;
use Illuminate\Support\Benchmark;

Benchmark::dd(
    benchmarkables: [
        fn () => User::count(),
        fn () => User::all()->count(),
    ],
    iterations: 10,
);

// The following will be dumped: ["0.5ms", "20.0ms"]

No External Tools Required

One of the benefits of using the Illuminate\Support\Benchmark class is that you don't need to set up any external tools or services to get started. You can use it directly within your Laravel application, making it easy to integrate into your existing workflow.

As a freelance Laravel developer, I'm often brought on board to work on existing projects. Sometimes, the client might not want data being sent to an external service for privacy or security reasons. Other times, they might not have the budget to pay for a dedicated profiling tool. Similarly, it might be difficult to get the application working with an external tool due to infrastructure or networking constraints, or because of the need to install/update Composer packages or PHP extensions. Or maybe you just want to quickly measure a piece of code's performance without the hassle of setting up an external tool.

So in these cases, the Benchmark class is a great alternative.

Things To Keep in Mind

Although the Benchmark class is a handy tool for measuring performance, there are a few important considerations to keep in mind when using it.

Not a Replacement for Dedicated Profiling Tools

It's important to remember that the Benchmark class only measures execution time and should be used as a guide rather than an absolute. It doesn't provide other important performance metrics, such as memory usage, database query counts, and so on. For these reasons, it's not a like-for-like replacement for proper profiling and performance monitoring tools such as Inspector, Laravel Nightwatch, or Blackfire. So if you're looking for a more in-depth performance analysis, I'd recommend using one of those tools instead.

However, this doesn't mean the Benchmark class isn't useful. It's still a fantastic tool that can help you quickly experiment with different approaches and optimisations.

Local vs Production Benchmarking

Another key point to remember is that no matter how closely you match your local environment to production, there will always be differences that can affect performance. Factors such as infrastructure, hardware capabilities, network setup and latency, dataset size, and traffic patterns can all impact performance in ways that are hard to replicate locally. So always treat the results as a guide rather than an absolute when benchmarking locally. Otherwise, you might end up making decisions based on inaccurate data.

If you don't want to, or aren't able to, use an external performance monitoring tool, the Benchmark class is still a great way to quickly measure performance in a production environment. For example, you could use it to measure the performance of a new feature or optimisation after deploying it to production, and log the results for later analysis. This way, you can gain better insight into how your changes perform in the real world. But remember that the results won't be as reliable or detailed as a proper profiling tool.

Running Benchmarks Multiple Times

In addition to ensuring benchmarks are run multiple times per run (via the iterations parameter), I also like to run the entire benchmark multiple times.

This helps account for any performance variability caused by external factors. For instance, your machine might have been running other unrelated processes in the background while you were running the benchmark, which may have slowed things down.

As an example, let's say you run the following code locally:

use App\Models\User;
use Illuminate\Support\Benchmark;

$executionTime = Benchmark::measure(
    benchmarkables: fn () => User::find(1),
    iterations: 10,
);

This means the benchmarked code will be run 10 times, and the average execution time will be returned. But if your machine was doing something resource-intensive in the background while all 10 of those closures were running, all of the runs may appear slower than they actually are. So I like to wait 30 seconds or so after running the benchmarks, and then run them again. I might do this 2 or 3 times in total.

Most of the time, the results will be similar across all runs. But in the past, I've had instances where the first run was significantly slower than subsequent runs, particularly on my older machine, which didn't have as much processing power or memory as my current one. If I'd have taken the results from just that first run, I may have made a decision based on inaccurate data.

Conclusion

In this article, we've looked at how to use the Illuminate\Support\Benchmark class in Laravel to measure the performance of different pieces of code. We've also discussed some important considerations for using it.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

Reduce Duplicate Cache Queries in Laravel with "Cache::memo()"

Ash Allen — Thu, 22 Jan 2026 00:00:00 +0000

Introduction

I recently wrote an article about how to use the once helper function for memoising data in Laravel applications. At the end of that article, I included a short section on alternative approaches, including the Cache::memo() method.

The Cache::memo() method is still relatively new (added to Laravel in v12.9.0 via PR #55304 by Tim MacDonald in April 2025), so I don't see it used very often in the wild. But I felt like it deserved its own article to expand on what it does and how it can be useful in your Laravel applications.

In this Quickfire article, we'll take a look at how to use the Cache::memo() method to reduce duplicated cache queries in Laravel applications to improve performance.

What is Memoisation?

To understand what the Cache::memo() method does, we first need to understand what memoisation is.

Memoisation is a technique in software and web development that involves temporarily storing the results of an expensive function call in memory so that subsequent calls can return the stored result rather than recalculating it. As a result, it can reduce the need to recompute the same value multiple times, or hit external services (like a database, API, or cache) repeatedly.

This means memoisation can sometimes provide significant performance improvements by avoiding duplicated, redundant operations.

If you want to see some other examples of memoisation in Laravel, you might be interested in checking out my "Memoisation in Laravel Using the "once" Helper" article.

Cache Memoisation with "Cache::memo()"

Now that we understand the idea behind memoisation, let's take a look at how we can use the Cache::memo() method in Laravel to reduce duplicated cache queries.

For all examples in this article, we'll assume our Laravel application uses Redis as its cache store.

To do this, let's first look at an example of duplicated cache queries that aren't using memoisation:

use Illuminate\Support\Facades\Cache;

$value = Cache::get('key'); // Hits the Redis cache
$value = Cache::get('key'); // Hits the cache again
$value = Cache::get('key'); // Hits the cache yet again

In the example above, we can see that we're retrieving the same cache key multiple times. With each call to Cache::get('key'), we're hitting the Redis cache store again, meaning we're making three separate requests to Redis.

Of course, in a real-world application, these calls would likely be happening in different parts of your codebase, but the end result is the same: we're making multiple requests to the cache store for the same data.

Although Redis and other cache stores are typically very fast, making multiple requests for the same data is still inefficient. In a high-traffic application, these duplicate queries can quickly add up and impact performance. So if there are any ways we can reduce these duplicated queries, it's usually a good idea to do so. Remember, lots of small optimisations can add up to a big overall performance improvement.

So let's look at how we can use the Cache::memo() method to solve this problem.

use Illuminate\Support\Facades\Cache;

$value = Cache::memo()->get('key'); // Hits the Redis cache
$value = Cache::memo()->get('key'); // Returns the memoised value, no cache hit
$value = Cache::memo()->get('key'); // Returns the memoised value, no cache hit

In the example above, we can see that we're using Cache::memo() and then calling get('key'). Using Cache::memo() tells Laravel to memoise the result of the cache query for the duration of the current request. On the first call to retrieve the cache value, Laravel will hit the Redis cache store as normal. It will then store the retrieved value in memory for the duration of the request and return the value. This means that the second and third calls will read the value from memory rather than hitting the Redis cache again.

This is great because it removes the need for us to hit the Redis cache multiple times for the same data within a single request when we request the value belonging to the key cache key.

Using Different Cache Stores

If no argument is passed to the Cache::memo() method, the default cache store defined in your Laravel application's configuration will be used. However, you can also specify a different cache store by passing the store name as an argument to the memo() method.

For example, if we wanted to explicitly use the redis cache store and memoise the values, we could do the following:

use Illuminate\Support\Facades\Cache;

Cache::memo('redis')->get('key'); // Hits the Redis cache
Cache::memo('redis')->get('key'); // Returns the memoised value, no cache hit

Modifying Cache Values

It's important to note that if you modify a cache value using Cache::memo(), the memoised value will be forgotten. This means the next call to retrieve the value will hit the cache store again.

Take this example:

use Illuminate\Support\Facades\Cache;

Cache::memo()->put('key', 'value'); // Writes to Redis
Cache::memo()->get('key'); // Hits the Redis cache
Cache::memo()->get('key'); // Returns the memoised value, no cache hit

Cache::memo()->put('key', 'new value'); // Forgets memoised value and writes to Redis
Cache::memo()->get('key'); // Hits the Redis cache again
Cache::memo()->get('key'); // Returns the memoised value, no cache hit

As we can see in the example above, the first Cache::memo()->get('key') call hits the Redis cache and memoises the value. The second call returns the memoised value from memory without hitting the cache again.

However, when we call Cache::memo()->put('key', 'new value'), it forgets the memoised value for that key. As a result, the next call to Cache::memo()->get('key') hits Redis again to retrieve the updated value, stores it in memory, and then returns it. The subsequent call then returns the newly memoised value.

Conclusion

Hopefully, this Quickfire article has given you a good overview of how to use the Cache::memo() method in Laravel to reduce duplicate cache queries in your applications. By leveraging memoisation, you can improve the performance of your applications by minimising redundant cache hits.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

How to Send Telegram Messages in Laravel

Ash Allen — Wed, 21 Jan 2026 00:00:00 +0000

Introduction

When you're building a Laravel application, you might want to send notifications to users via Telegram. This is useful for things like sending updates and alerts. For example, I'm subscribed to Telegram notifications on sites like Oh Dear to notify me of any downtime or issues with my sites. This means if any of my sites or my clients' sites go down, I get an instant notification via Telegram so I can quickly investigate and resolve the issue.

In this article, we're going to take a quick look at how to send Telegram messages from your Laravel application.

Before we get stuck in, you might also be interested in some of my other notification-related articles:

Setting Up Your Telegram Bot

In order to send messages via Telegram, you'll first need to create a bot in the Telegram app. This bot will be responsible for sending messages to users on your behalf.

The Telegram documentation provides a nice guide on creating a bot. The basics are that you need to start a chat with the "BotFather" user in Telegram. This will launch a conversation where you can create and manage your bots.

Telegram bots are incredibly powerful and are packed with features. So I recommend spending some time exploring the different options available when setting up your bot so it best suits your needs.

Installation

To send the Telegram notifications, we'll use the laravel-notification-channels/telegram package. The package provides a new notification channel that taps into Laravel's existing notification system, making it super easy to send Telegram messages. At the time of writing this article, the package has 3.1 million installs and 1.1k stars on GitHub.

You can find the GitHub repo for the package here: https://github.com/laravel-notification-channels/telegram

To install the package, you can run the following command in your project root:

composer require laravel-notification-channels/telegram

The package should now be installed and ready to use.

Getting the Chat ID

In order to send a message from your Telegram bot to a user, you first need to know the user's chat ID. A bot cannot initiate a conversation with a user. This means the user must have first interacted with the bot (for example, by sending it a message or clicking the "Start" button within Telegram) to start the chat.

Once the user has interacted with your bot and started a chat, you can retrieve the chat ID so it can be used to send messages. There are multiple approaches to getting the chat ID. For example, you could use the notification channel package's built-in class to fetch channel updates. Then you can search through the updates to find the chat ID of the user you want to send a message to. The package's documentation shows how you can do this.

Another approach is to configure your Telegram bot to send a webhook to your Laravel application when a conversation starts. From there, you can store the chat ID (sent in the webhook) in your database against the user.

However, I'm not going to cover this in detail here, as it's beyond the scope of this article, and you'll use a different approach depending on your use case.

But please remember, whichever approach you use, keep security in mind. You don't want to add any vulnerabilities that allow someone to send messages to arbitrary chat IDs.

Sending Notifications

For Laravel's notification system to know where to send Telegram notifications, we need to define a new routeNotificationForTelegram method on the notifiable model (usually App\Models\User). In this case, we'll assume that we're storing the user's Telegram chat ID in a telegram_chat_id column on the users table. We can then return this value from the routeNotificationForTelegram method like so:

declare(strict_types=1);

namespace App\Models;

use App\Casts\NotificationPreferences;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

final class User extends Authenticatable
{
    use Notifiable;

    // ...

    public function routeNotificationForTelegram(): int
    {
        return $this->telegram_chat_id;
    }
}

Now let's create our notification. For the purposes of this article, we'll create a simple notification class that can notify a user when the status of their order in our online store is updated. We'll include a button in the Telegram message that directs the user to our web application to view their order.

We can create the notification by running the following Artisan command:

php artisan make:notification OrderUpdated

We should now have a new notification class at app/Notifications/OrderUpdated.php. Let's update this class to send a Telegram message, and then we'll discuss what's being done:

declare(strict_types=1);

namespace App\Notifications;

use App\Models\Order;
use App\Models\User;
use Illuminate\Bus\Queueable;
use Illuminate\Notifications\Notification;
use NotificationChannels\Telegram\TelegramMessage;

final class OrderUpdated extends Notification
{
    use Queueable;

    public function __construct(private Order $order)
    {
        //
    }

    /**
     * Get the notification's delivery channels.
     *
     * @return array<int, string>
     */
    public function via(): array
    {
        return ['mail', 'telegram'];
    }

    // ...

    public function toTelegram($notifiable): TelegramMessage
    {
        return TelegramMessage::create()
            ->line('Hello there!')
            ->line("Your order status has been updated")
            ->button('View Order', route('order.show', $this->order));
    }

}

In the code example above, we can see that we're starting by passing in an App\Models\Order instance to the notification's constructor. We haven't included the code for this model for brevity, but we can assume it holds information about a user's order.

We're then using the via method to specify that we want to send the notification via both email and Telegram. In this case, we're only focusing on the Telegram part, so I've left out the email-specific code.

Next, we have the toTelegram method. This method builds and returns the actual Telegram message to be sent to the user. We're using the NotificationChannels\Telegram\TelegramMessage class provided by the notification channel package to create a new message. We're defining that the message should include two lines of text, followed by a button that the user can click to view their order.

Now that we've defined our notification, we should be able to send it to our user. Let's take this super simple code snippet, which finds a user and an order, then sends the notification to the user:

use App\Models\Order;
use App\Models\User;
use App\Notifications\OrderUpdated;

$user = User::find(1);
$order = Order::find(1);

$user->notify(new OrderUpdated($order));

If everything is configured correctly, the user should receive a Telegram message from your bot notifying them that their order status has been updated.

Sending a Location

The package also allows us to send different types of messages. For example, you can send a location message, which will display a location pin on a map in the Telegram app. You can do this by passing the latitude and longitude to the NotificationChannels\Telegram\TelegramLocation class like so:

declare(strict_types=1);

namespace App\Notifications;

use Illuminate\Notifications\Notification;
use NotificationChannels\Telegram\TelegramLocation;

final class OrderUpdated extends Notification
{
    // ...

    public function toTelegram($notifiable): TelegramLocation
    {
        return TelegramLocation::create()
            ->latitude('51.5072')
            ->longitude('0.1276');
    }
}

Sending Images

You can also send images to users via Telegram. You can do this by using the NotificationChannels\Telegram\TelegramFile class and specifying the file URL or path along with the type of file (in this case, a photo) like so:

declare(strict_types=1);

namespace App\Notifications;

use Illuminate\Notifications\Notification;
use NotificationChannels\Telegram\TelegramFile;

final class OrderUpdated extends Notification
{
    // ...

    public function toTelegram($notifiable): TelegramFile
    {
        return TelegramFile::create()
            ->content('Here is an image:')
            ->file(file: 'https://example.com/image.png', type: 'photo');
    }
}

Other Messages Types

The package also provides other message types that you can send, such as:

Audio
Document
Polls
Stickers
GIFs
Venues

I think the documentation already does a pretty great job of explaining how to send these different message types, along with examples of what the message will look like in Telegram to the user. So if you're interested in sending any of these other message types, I recommend checking out the package's documentation.

On-Demand Notifications

There may also be times when you want to send a notification to a Telegram chat ID that isn't associated with a user in your application. You can do this by sending an on-demand notification using the Illuminate\Support\Facades\Notification::route method like so:

use App\Models\Order;
use App\Notifications\OrderUpdated;
use Illuminate\Support\Facades\Notification;

$order = Order::find(1);

Notification::route('telegram', '123456789')
    ->notify(new OrderUpdated($order));

In the example above, we've specified that we should send the App\Notifications\OrderUpdated notification to the Telegram chat ID 123456789. This allows you to send notifications to arbitrary chat IDs without needing to have a user model associated with them, which can be pretty handy.

Conclusion

Hopefully, this article has given you a quick overview of the basics of sending Telegram messages in Laravel using the laravel-notification-channels/telegram package. The package makes it super easy to integrate Telegram notifications into your Laravel application by leveraging Laravel's existing notification system.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

Memoisation in Laravel Using the `once` Helper

Ash Allen — Tue, 20 Jan 2026 16:19:51 +0000

Introduction

When building Laravel applications, there may be times when you need to use a value multiple times within the same request lifecycle, but calculating it is expensive or time-consuming. A possible solution optimise performance in these scenarios is "memoisation" (or "memoization").

Memoisation is the technique of temporarily storing the result of an expensive function call so that subsequent calls to that function return the cached result rather than recalculating it. If you've used caching before, memoisation is pretty similar, except that it generally lasts only for the duration of a single request, at least in the context of Laravel. Depending on the use case, it can help to reduce calls to databases, external APIs, cache stores, or methods that take a long time to run.

In this article, we're going to take a look at how to use Laravel's built-in once helper function to implement memoisation in your applications. We'll also explore the differences between using once inside functions and within object methods, including static methods. We'll then explore how Laravel Octane integrates with the once helper to ensure that memoised values are reset between requests. Finally, we'll briefly discuss other approaches to memoisation in Laravel.

Using the "once" Helper in Laravel

The once helper function in Laravel is really simple to use. It accepts a closure as an argument; the first time it's called, it returns the closure's result and stores it for future calls within the same request. On subsequent calls, it returns the cached result instead of executing the closure again. Unless the value is cleared, the cached result will persist for the duration of the request. After the request completes, the cached value is discarded. This means a value memoised with once in a request cannot be accessed in any other requests.

Let's take a look at a simple example. So we can focus on the memoisation aspect rather than any specific business logic, we'll just imagine our calculateExpensiveValue function performs an expensive calculation. We'll return the result of random_int to highlight that the value is only calculated once.

Imagine we have this function, which isn't using any form of memoisation:

function calculateExpensiveValue(): int
{
    // Imagine this function performs an expensive calculation. We'll
    // use the "random_int" function to simulate this.

    return random_int(min: 1, max: 100);
}

echo calculateExpensiveValue(); // e.g., outputs: 42
echo calculateExpensiveValue(); // e.g., outputs: 57
echo calculateExpensiveValue(); // e.g., outputs: 13

As we can see, the output changes each time we call the function because it recalculates the value every time.

Let's take a look at what happens when we wrap the calculation in the once helper:

function calculateExpensiveValue(): int
{
    // Imagine this function performs an expensive calculation. We'll
    // use the "random_int" function to simulate this.

    return once(
        static fn (): int => random_int(min: 1, max: 100)
    );
}

echo calculateExpensiveValue(); // e.g., outputs: 42
echo calculateExpensiveValue(); // outputs: 42
echo calculateExpensiveValue(); // outputs: 42

As we can see, the output remains the same for each call to calculateExpensiveValue because the result of the first call is cached and returned on subsequent calls.

Using "once" Inside Objects

There are a few "gotchas" to be aware of when using the once helper inside objects, particularly when it comes to instance methods versus static methods. So I wanted to quickly cover them here so you don't make the same mistakes as I've made in the past.

Using "once" in Methods

Let's stick with our previous example, but this time we'll put the calculateExpensiveValue function inside a class as a method:

declare(strict_types=1);

namespace App\Services;

final readonly class NumberService
{
    public function calculateExpensiveValue(): int
    {
        return once(
            static fn (): int => random_int(min: 1, max: 100)
        );
    }
}

Now let's call this method a few times:

use App\Services\NumberService;

$numberService = new NumberService();

dump($numberService->calculateExpensiveValue()); // e.g., outputs: 42
dump($numberService->calculateExpensiveValue()); // outputs: 42
dump($numberService->calculateExpensiveValue()); // outputs: 42

$anotherNumberService = new NumberService();

dump($anotherNumberService->calculateExpensiveValue()); // e.g., outputs: 57
dump($anotherNumberService->calculateExpensiveValue()); // outputs: 57
dump($anotherNumberService->calculateExpensiveValue()); // outputs: 57

As we can see, the output is consistent for each instance of the App\Services\NumberService class, but different between instances. This is because the once helper caches the result per object instance.

This has caught me out in the past because I assumed the cached value would be shared across all instances of the class, in a similar way to static properties. But as we can see, that's not the case.

Using "once" in Static Methods

However, when the method is static, it is not tied to a specific instance of the class. Instead, it's tied to the class itself, so the cached value is shared across all calls to the static method.

Let's look at what I mean by this. We'll update our calculateExpensiveValue method to be static:

declare(strict_types=1);

namespace App\Services;

final readonly class NumberService
{
    public static function calculateExpensiveValue(): int
    {
        return once(
            static fn (): int => random_int(min: 1, max: 100)
        );
    }
}

And we'll call the static method a few times:

use App\Services\NumberService;

$numberService = new NumberService();

dump($numberService::calculateExpensiveValue()); // e.g., outputs: 42
dump($numberService::calculateExpensiveValue()); // outputs: 42

dump(NumberService::calculateExpensiveValue()); // outputs: 42
dump(NumberService::calculateExpensiveValue()); // outputs: 42

As we can see, the output remains consistent across all calls to the static method.

Using "once" with Laravel Octane

As I mentioned at the beginning of the article, memoised values created with the once helper are stored in memory and last only for the duration of a single request. This means requests can't access the memoised values of other requests, and when a request completes, the cached values are discarded.

However, you might be wondering how this works when using Laravel Octane, which keeps your application in memory between requests to improve performance. In this case, if the memoised values were not cleared between requests, they would persist across requests, which is not the intended behaviour.

Laravel Octane handles this in a really cool way by providing an event listener that flushes the memoised values at the end of each request lifecycle. This ensures that each request starts with a clean slate, and any memoised values are recalculated as needed. Let's take a look at how this is implemented.

Octane's config file (located at config/octane.php) includes a listeners array where various event listeners are registered. The Laravel\Octane\Listeners\FlushOnce listener is registered to listen for the Laravel\Octane\Contracts\OperationTerminated event like so:

use Laravel\Octane\Contracts\OperationTerminated;
use Laravel\Octane\Listeners\FlushOnce;

return [

    // ...

    /*
    |--------------------------------------------------------------------------
    | Octane Listeners
    |--------------------------------------------------------------------------
    |
    | All of the event listeners for Octane's events are defined below. These
    | listeners are responsible for resetting your application's state for
    | the next request. You may even add your own listeners to the list.
    |
    */

    'listeners' => [
        // ...

        OperationTerminated::class => [
            FlushOnce::class,
            // ...
        ],

        // ...
    ],

    // ...

];

So when the Laravel\Octane\Contracts\OperationTerminated event is fired at the end of each request, the Laravel\Octane\Listeners\FlushOnce listener is executed. This listener calls the Illuminate\Support\Once::flush method to clear all memoised values:

namespace Laravel\Octane\Listeners;

use Illuminate\Support\Once;

class FlushOnce
{
    /**
     * Handle the event.
     *
     * @param  mixed  $event
     */
    public function handle($event): void
    {
        if (class_exists(Once::class)) {
            Once::flush();
        }
    }
}

The flush method achieves this by setting the static $instance property of the Illuminate\Support\Once class to null, effectively discarding all cached values:

namespace Illuminate\Support;

use WeakMap;

class Once
{
    /**
     * The current globally used instance.
     *
     * @var static|null
     */
    protected static ?self $instance = null;

    // ...

    /**
     * Create a new once instance.
     *
     * @param  \WeakMap<object, array<string, mixed>>  $values
     */
    protected function __construct(protected WeakMap $values)
    {
        //
    }

    /**
     * Create a new once instance.
     *
     * @return static
     */
    public static function instance()
    {
        return static::$instance ??= new static(new WeakMap);
    }

    // ...

    /**
     * Flush the once instance.
     *
     * @return void
     */
    public static function flush()
    {
        static::$instance = null;
    }
}

Although this is all handled automatically by Laravel Octane, it's good to understand how it works under the hood so you can be confident that your memoised values are being managed correctly. Reading vendor code like this is also a great way to learn more about how things work internally.

Other Approaches to Memoisation in Laravel

Although the once helper is a great built-in way to handle memoisation in Laravel, there are other approaches you may want to take into consideration depending on your specific use case.

The techniques I'll mention here might not be strictly considered "memoisation". But they can achieve similar results by holding a value that can be reused and improving performance.

The "Cache::memo" Method

Laravel ships with a handy memo method which can be used when interacting with the cache. It holds the value retrieved from the cache in memory so that subsequent calls to retrieve the same cache key within the same request do not hit the cache store again. Here's an example of how to use it:

use Illuminate\Support\Facades\Cache;

$value = Cache::memo()->get('key'); // First call hits the cache store
$value = Cache::memo()->get('key'); // Subsequent calls return the value from memory

If we assume we're using Redis as a cache store, the first get call would hit the Redis server to retrieve the value associated with the key. However, the second call would return the value stored in memory by the memo method, avoiding an additional round-trip to the Redis server. Although fetching values from Redis is usually fast, avoiding unnecessary network calls is always a good idea, especially in high-traffic applications.

The "array" Cache Store

Another approach you can use, which I don't see used too often, is the array cache store. This driver stores cached values in an in-memory array for the duration of the request, allowing them to be reused multiple times within the same request without hitting an external cache store.

I've actually written about it before in a past blog post, so I won't go into too much detail here. But here's a quick example of how to use it:

use Illuminate\Support\Facades\Cache;

Cache::store('array')->put('key', 'value', 60); // Store value in array cache

$value = Cache::store('array')->get('key');
$value = Cache::store('array')->get('key');

In all fairness, I don't generally have a use case for this approach in my applications, but it's always worth knowing about the different techniques available to you. Sometimes knowing about these things can spark ideas for optimisations you might not have thought of otherwise.

However, it's worth noting that the Laravel documentation specifically states that the array driver "provides a convenient cache backend for your automated tests". This suggests to me that it might not be the best choice for production applications, so use with caution.

Properties and Static Properties

Another approach to memoisation is to simply use class properties or static properties to store values that you want to reuse within the same request. This is a straightforward approach that can work well in many scenarios. In essence, this is all the once helper does under the hood, except with additional management to ensure the values are scoped correctly and so on.

For example, you could use a class property to hold a value that is expensive to calculate:

declare(strict_types=1);

namespace App\Services;

final class NumberService
{
    private ?int $expensiveValue = null;

    public function calculateExpensiveValue(): int
    {
        // If the value has already been calculated, return it.
        // Otherwise, calculate it and store it in the property.
        return $this->expensiveValue ??= random_int(min: 1, max: 100);
    }
}

$numberService = new NumberService();

echo $numberService->calculateExpensiveValue(); // e.g., outputs: 42
echo $numberService->calculateExpensiveValue(); // outputs: 42

Although this seems like an obvious solution to just hold the value in a property, sometimes we can overlook the simple solutions. Just remember, if you go down this route, be mindful of the scope of the property (i.e., instance vs static) and how that affects the lifetime of the cached value. You have to remember that static properties can be shared across requests when using Laravel Octane, so you'll need to manage them accordingly and reset the value at the end of each request if necessary.

Conclusion

Hopefully, this article has given you a good understanding of how to use the once helper in Laravel for memoisation, as well as the nuances of using it within object methods. We've also explored how Laravel Octane integrates with the once helper to ensure that memoised values are reset between requests.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

Using AI to Build a Laravel Feature with Junie in PhpStorm

Ash Allen — Fri, 16 Jan 2026 15:46:25 +0000

I've recently been giving Junie a try in PhpStorm to see how helpful it can be when working on Laravel projects.

If you're not familiar with Junie, it's JetBrains' AI assistant that integrates directly into their integrated development environments (IDEs), including PhpStorm. I mentioned in a previous article that I've been using it to help me debug issues and write new code. So far, it's been a pretty positive experience. There are times when it doesn't quite get things right or misunderstands what I'm asking it to do, but overall, I've found it surprisingly useful.

So I thought I'd record a video showing how to use Junie in PhpStorm. In the video, I try to use Junie to add a new settings page to a fresh Laravel application that is using the Vue.js starter kit.

It's not one of those "Wow, look how amazing AI is!" types of videos (spoiler alert: it actually struggles to build what we need towards the end). But I thought it was a good demonstration of how Junie can help you build features in a Laravel application. It isn't perfect, but it can definitely speed things up when it works well.

P.s - Please excuse the poor audio quality in the video. I only realised during editing that I'd recorded it using my laptop's built-in microphone rather than my usual external one. Ooops!

How AI Will Impact My Job as a Freelance Web Developer in 2026

Ash Allen — Tue, 13 Jan 2026 22:01:18 +0000

Introduction

Over Christmas and New Year, I took a 2-week break from work to recharge my batteries. I wanted to take some time away from my laptop and avoid anything web development-related so I could have a proper mental reset. So on Monday morning last week, when I opened up my laptop and went to X for the first time in 2 weeks, I was curious to see what I’d been missing in the web development world.

The first 10 or so posts that I saw on my feed were all about AI in some way. I mainly saw screenshots of agents running and people sharing that they’d managed to get the AI to build something cool for them in a short time.

Then, as the week progressed, I saw that there had been layoffs (including at Laracasts and Tailwind, which was a huge shock), which were in part due to the impact of AI on the web development industry. Layoffs are the type of thing which is always sad to see. It’s hard for the employees who’ve just lost their jobs, and it’s hard for the business owners who have to make those tough decisions. I felt for everyone involved, and I don’t envy the business owners who had to make those decisions because I’m sure they weigh heavily on their minds. My heart goes out to everyone involved in those situations.

But all this got me thinking about how AI will impact me as a freelance web developer in 2026, and I wanted to share my thoughts.

Before we dive in, I want to say that I’m by no means an expert on AI. So there might be things in here that I get wrong, and maybe some things that I haven’t even considered. But I want to put these thoughts on paper (or screen) so that I can reflect on them later. I’d be really interested to come back to this post in a year’s time and see how my thoughts have changed (if at all).

My Initial Thoughts

I’ll be completely honest, my first thoughts after reading the posts on X and seeing the layoffs were “Uh oh! Am I going to start losing work because of AI?”. I got that sinking feeling in my stomach along with a crushing wave of anxiety. After all, I need to sell my web development services to make a living and pay my bills.

But after thinking about it more, I realised that AI is just another tool. And rather than seeing it as a threat, I should see it as an opportunity. After all, I’ve been using it for the past couple of years, and it’s only helped me be more productive and efficient.

How I’ve Been Using AI

I’ve been using AI in various ways over the past couple of years to help with my workload:

Writing Code with GitHub Copilot

As you’d expect, as a web developer, the most obvious way I’ve been using AI is to help me write code. Now that doesn’t mean I’ve been using it to write entire applications for me. Instead, I’ve been using GitHub Copilot in PhpStorm to help me write short code snippets. I treat it like an autocomplete-on-steroids tool.

I’ll typically get halfway through writing a line of code, and Copilot will suggest the rest of the line for me.

When I first started using Copilot a few years ago, I’d say less than 50% of its suggestions were useful. I usually ignored them and just wrote the code myself. But over time, as it’s improved, I’ve found that these suggestions are exactly what I wanted to write most of the time. So now I accept the suggestions more often than not.

I’ve found that when it generates entire blocks of code, the results are a bit more hit-or-miss. Sometimes it gets it right, but other times it misses the mark completely, producing bloated, over-engineered, or just plain incorrect code. But even when this happens, it still helps me because it gives me alternative approaches to solving a problem that I might not have thought of myself, which can then inspire me to come up with a better solution.

Generating Code with Agents

I can’t give too many details away since this is related to a client’s project, but at the end of 2025, I was asked to build a new feature for a client’s application. It was the type of feature that makes you think, “Oh man! How am I going to build this?”. I kept avoiding the work and just kept picking other tasks off the to-do list instead. It’s not that I didn’t think I could build it; it’s just that I knew it would be a difficult task with a ton of edge cases to consider. I’m not sure exactly how long it would have taken me to build it myself, but I expected it would be at least a few days.

But as an experiment, as a team, we used Cursor to build the feature to see how well it would perform. We gave it a detailed brief of what we wanted the feature to do and left it to run. About 9 minutes later, it came back with a near-perfect implementation of the feature. It had even considered edge cases which we hadn’t mentioned to it ourselves.

Just let me reiterate that: It built a complex feature in under 10 minutes that would have taken me days to build myself.

It’s incredible!

And this is what amazes me most about AI tools. I’d been feeling the dread (dread might be too strong a word, but I’m sure you get the point I’m trying to make) and anxiety of having to build this feature. I’d been thinking about different ways I could tackle it while outside of work hours, such as when taking the dog out for a walk, cooking food, or going for a run. And this AI tool just built it for us in minutes. No emotion, no stress, no anxiety. To me, I find that absolutely mind-blowing.

Debugging and Fixing Issues

In the pre-AI days, when I encountered a bug, my workflow typically involved Googling the error message or problem I was facing. I’d then sift through the search results to find a solution. Sometimes I’d be able to find a solution quickly, but other times it would take a while to find something that fit my specific situation. As you’ll probably have experienced yourself, this can lead to a ton of open tabs in your browser as you sift through different blog posts and Stack Overflow answers trying to find the right solution.

But my workflow has changed. Now, when I encounter a bug, the first thing I do is try to figure out the issue myself (just like I did before). I’ll only spend about 5 minutes on this, but I might spend more time if it means diving into vendor code (I find this particularly useful for learning how things work under the hood). If I can’t find the issue myself, I’ll then ask an AI tool, such as Junie (the AI assistant built into PHPStorm) or ChatGPT. Finally, if neither of them can help me diagnose the issue, I’ll then Google the issue and see if I can find a solution that way on blog posts or videos.

It blows my mind how much my debugging workflow has changed and how much faster I can now diagnose issues compared to before AI tools were available. I’d make a guess that at least three-quarters of the bugs I encounter these days are solved by the AI tools, so I never even make it to the Google search stage.

I can’t give too many details, but I was recently trying to fix a tricky bug on a client’s application. I spent a bit of time trying to figure out what was causing it, but couldn’t seem to get to the bottom of it. So I asked Junie for help and explained what the problem was and what I expected the desired outcome to be. Within a minute or so, Junie had identified the root cause of the issue, written a full explanation of the problem (turns out it was some magic methods hidden deep in a third-party package that were interfering with the expected behaviour), and even provided a code snippet to fix the issue. I was blown away by how quickly it helped me diagnose and fix the problem.

I then tested the fix, and it worked perfectly. In fact, it was so perfect that when I opened the PR to fix the issue, I copied and pasted Junie's explanation because it was so clear and concise (don’t worry, I didn’t try to claim it as my own work!). I hadn’t written a single line of code to fix the issue myself. I still think that’s crazy!

Another great example of how I’ve used AI was when I was recently setting up some new app servers for my websites. I won’t bore you with the details, but I ran into a few issues related to Node and NPM versions. I explained the issue to ChatGPT, and after a bit of back-and-forth, it helped me solve the problems. It gave me the exact commands to write (including explanations of what each command did) to get everything working perfectly. Before you read that thinking “Ash, you shouldn’t be blindly copying and pasting commands from AI tools into your terminal”, don’t worry, I completely agree with you! I would have eventually figured out the commands myself if I’d written them manually, but ChatGPT just sped up the process for me. So they were completely safe.

Writing Articles and my Books

I tend to write my blog articles in PhpStorm, and I also wrote my three books (Battle Ready Laravel, Consuming APIs in Laravel, and The Web Dev's Guide to Freelancing) using it. Now, that might seem like a weird choice, but let me explain why.

The content of my articles and books is all written as Markdown files. I then copy the contents of the Markdown files into my blog’s backend or use external tools to convert them into PDFs and EPUBs for my books.

I start by writing my code examples, then add bullet points in each section outlining what I want to cover. Once I’ve got that rough outline, I go through the sections one by one and expand the bullet points to turn them into full paragraphs. This is the approach I’ve used for doing any writing, going all the way back to when I was 15-16 years old in school. It’s an approach that works well for me because it allows me to get my main talking points down quickly without getting bogged down in the details of writing full sentences and paragraphs.

However, I’ve found that AI tools have helped me improve this process even more. For example, let’s say I have a bullet point but don’t know how to turn it into a full sentence or paragraph (sometimes finding the right way to start a sentence is the hardest part!). Since I’m writing in PhpStorm, I can let Copilot auto-suggest the beginning of the sentence for me. For me, this is a huge win because it helps me overcome writer’s block and get the words flowing more easily.

By no means would I ever use it to write entire articles or books for myself. I still want to be the one writing the content because I want it to be my voice and my style. Heck, I feel like a “cheater” and a “fake” when I let it write just a couple of words to start a sentence. But having AI tools help me with the small bits of writing here and there (such as helping me to start a tricky sentence) has made the process much smoother and more enjoyable. This means I can produce more content in less time, which is a win-win for both my readers and me.

How My Job Might Change in 2026 and Beyond

As I said at the beginning of this article, my initial thoughts at the beginning of this year were ones of anxiety and fear about how AI might impact my job as a freelance web developer.

But after spending time reflecting on it, I’ve realised that AI is just another tool for me to use. I strongly believe that the type of work I do (or at least the workflow I use) will change significantly over the next few years as AI tools become more advanced and capable. And, to be honest, I find it quite exciting!

As a Freelance Web Developer

Whenever I speak to developers who were writing code in the early 2000s or late 90s, I hear things like “Back then, we had to do [SOMETHING SERIOUSLY LONG WINDED AND TEDIOUS] manually”. Then I’d reply saying, “Wow, that sounds awful! Now we can do it with a single line of code”.

I have a strong feeling that, in a few years' time, developers will be saying the same thing about AI. They’ll look back and think, “I can’t believe we used to write all that code ourselves manually. What a waste of time!”.

To what extent this will happen, I don’t know. Maybe I’ll continue using AI tools as an autocomplete tool, or maybe I’ll start using agents that can build entire features for me. But either way, I have a feeling that my role as a web developer is going to shift quite a bit.

Pricing My Work

As I’ve mentioned, I’ve already played around with using Junie for writing code and debugging issues, and it’s felt like it’s given me superpowers. I’ve been able to deliver features faster and fix bugs more quickly than ever before. This is absolutely fantastic for my clients and me because it means I can take on more work and deliver it faster.

But this introduces a minor business issue for me. At the time of writing this article, I charge £60/hour for any new freelancing work I take on. Let’s say, for example, that I could build a feature in 8 hours without AI assistance; that would cost the client £480. But if I use an AI agent to build the feature for me, and it only takes me 2 hours to review and test the code, that would only cost the client £120. This is a huge saving for the client (which is awesome for them!), but it also means that my revenue from that work has dropped significantly.

Every freelance developer hits these issues as they get more efficient at what they do. We raise our prices as we get faster over time to compensate for the fact that we spend less time doing the same amount of work. It’s actually something I talk about in the “How Much Should I Charge?” section of The Web Dev’s Guide to Freelancing, where I talk about making sure you get paid a fair amount. But with AI, the speed increases will be exponential. Rather than being able to build a feature twice as fast, I might be able to build it 4x or even 10x faster. Does this mean I’d need to increase my hourly rate to £600/hour to maintain the same revenue? Absolutely not, that’s crazy!

So this is where I’m probably going to need to rethink my pricing and business model. For long-term contracts where I’ve been hired to provide a given number of hours per week/month and pick issues/features off a Trello/Linear board to implement, I can likely continue charging by the hour. It just means I’ll get through the work faster than before and can move on to the next feature sooner. So nothing really changes there.

But for fixed-price projects, I might need to tweak my pricing strategy. Usually, I’d take a rough estimate of how long I think it will take me to build a feature, then multiply that by my hourly rate to get a fixed price for the client. I’ll then make any tweaks to the price based on the “value” that the work is providing for the client. We need to remember, when pricing, that we’re not just selling our time; we’re selling the value our work provides to the client.

But with AI assistance, since I’ll be building them faster than before, I might need to adjust how I price these types of projects. Maybe I’ll need to reduce the weight my time has in the overall price and increase the weight the value has. This way, even if I build the feature in a quarter of the time, I can still charge a fair price that reflects the value the feature provides to the client. You could argue that I should already be pricing this way in the first place, but it’s an approach that’s worked for me so far, so I haven’t felt the need to change it until now because it provides me with a predictable, consistent flow of work and income.

Switching from Code Writer to Code Reviewer

As I’ve already mentioned, AI tools can generate some pretty good code. But I’ve also seen it produce bloated, over-engineered code that needs significant refactoring. I’ve also seen it produce code that looks fine on the surface but misses some edge cases that could lead to bugs later. It’d be easy for someone to blindly accept the AI-generated code without fully reviewing it (or understanding what it’s doing) and miss these issues. But as an experienced developer, I know what to look for and can catch these issues before they reach production. And it’s easy to miss these types of edge cases when you’re reviewing AI-generated code because you’re not as deeply immersed in the problem as you would be if you were writing the code yourself.

I used Junie this week to generate the boilerplate code for a new feature I was building for a client’s project. It wrote 331 lines of code for me, and I’d say it got the feature 50% of the way there. I’d guess it saved me roughly 2-3 hours of development time. I then manually wrote the final 50% of the code and tweaked the generated code. I noticed that, of the 331 lines, around 40-50 were unnecessary and could be removed and simplified. These lines weren’t necessarily wrong, and they did achieve the desired outcome when run, but they were just completely overcomplicated. So if we were to imagine a scenario where we blindly accepted the suggestions, and we added 10 new features, that’d result in 400-500 unneeded lines of code. That’s extra code to maintain, extra code to write tests for, and extra code which could introduce potential bugs or vulnerabilities.

So I think the value I can provide is knowing how to use AI tools effectively. Mainly by knowing what to ask the AI, how to review the generated code and ensure that it actually meets the requirements without introducing bugs or security issues, and how to test the code properly to ensure that it works as expected.

For these reasons, I have a feeling my workflow will change over the coming years, from being a code writer to more of a code reviewer. I’ll still be writing some code myself and building features, but just nowhere near as much as I do now.

I don’t know if that’s a good thing or a bad thing. I really enjoy writing code and solving problems. It’s such a good feeling when I’ve been spending hours trying to get a particular feature working exactly how I want it, and then it finally starts working perfectly. It gives me a huge sense of satisfaction and feels like an achievement.

But I don’t get that same feeling when I’m generating code. Don’t get me wrong, I’m still absolutely amazed when Junie writes some code for me in minutes that would have taken me hours to build myself. But I don’t get that same sense of achievement because I didn’t actually write the code myself. The AI did that for me.

At the end of the day, though, my goal is to deliver value to my clients. If using AI tools helps me deliver features faster and more efficiently, then I’m all for it. Clients don’t care how the code gets written; they just care that it works and meets their needs.

I just hope that I don’t “forget” how to write code manually because I’m relying on AI tools too much. I want to make sure I still have the skills and knowledge to write code myself if needed. I have a feeling I might keep writing code manually for my open-source packages and personal projects just so I can keep my skills sharp.

Fixing AI-Generated Issues

Currently, I’m hired quite often by teams who get in touch and say, “We have a load of bugs in our code that we need fixing. Can you help?”. These are usually bugs introduced over years of development and that have built up over time. I then join the project and get to work with fixing the issues, writing tests, and improving the overall code quality.

I’m wondering whether AI will increase these types of enquiries for me. As I mentioned, it’s really easy to generate bad code if you don’t know what you’re looking for. So I wonder whether more projects will start to see an increase in bugs, issues, and spaghetti code because of poorly implemented AI-generated code. If this happens, I could see more teams reaching out to me to help them fix these issues.

Of course, this might not happen if the AI tools get better at generating high-quality code or fixing issues themselves. But I have a feeling that there will always be a need for experienced developers who can review and fix AI-generated code.

As a Content Creator

As I’ve mentioned, my workflow for solving issues has changed significantly because of AI tools. Blogs, videos, and Stack Overflow posts used to be my go-to resources for finding solutions to problems. But now, I turn to AI tools first because they can provide tailored solutions specific to my situation without leaving my IDE. And I suspect I’m not the only one doing this.

I’ve seen a huge decrease in the visitors to my blog over the past year or so. Of course, this could be down to many different factors, such as changes in search engine algorithms. But from reading online, it seems many other content creators are seeing similar drops in traffic. And the general consensus is that AI tools are a major reason.

So I think the type of content I create will need to change over the coming years. Rather than writing blog posts that provide solutions to specific problems, I might need to focus more on creating content that shows readers new things. For example, let’s say you want to add some JSON Web Tokens (JWT) to your application. You could likely ask an AI tool to generate the code for you. But to be able to ask the AI, you need to know in the first place that JWTs are even a thing. After all, you don’t know what you don’t know.

For this reason, I think my content will need to focus more on introducing readers to new concepts and ideas they might not have heard of before. Then they can take that knowledge and use AI tools to help them implement those concepts in their own projects. Or, maybe I’ll write more opinion pieces if that’s something that people find valuable.

Just like with code, I really enjoy writing articles and content, so even if the traffic completely dries up, I don’t think I’ll stop writing. I like writing about things I’ve just learnt so I can refer back to them later. I just might need to adjust my expectations about how much traffic my content will get in the future.

Final Thoughts

If you’ve made it this far, thank you for sticking with me and my rambling thoughts. I’d be really interested to hear your thoughts on how AI is going to impact your job in 2026 and beyond. Do you think it’s going to be a big change, or do you think things will stay relatively the same?

As I say, I’m by no means an expert on AI, so there might be things that I’ve missed or got wrong. But I wanted to make sure I jotted down my thoughts because I think 2026 is going to be a scary but exciting year for web developers like us.

Formatting PHP Code with PHP CS Fixer

Ash Allen — Thu, 18 Dec 2025 16:37:43 +0000

Introduction

Maintaining a consistent code style is a key aspect of software and web development. It improves code readability, reduces developers' cognitive load, and ensures everyone on the team sticks to the same standards.

But manually formatting code style is time-consuming, tedious, and error-prone. It's possible to format your code automatically using your integrated development environment (IDE) or text editor, but this approach has its limitations. Not all team members may use the same tools, and IDE configurations can vary widely. So it's usually better to use a dedicated code style tool that can be run consistently across different environments and in your continuous integration (CI) pipeline.

One of the tools you can use for formatting your PHP code is PHP CS Fixer. It's an incredibly popular tool and, at the time of writing, has over 214 million downloads on Packagist.

In this article, we'll look at how to install and configure PHP CS Fixer. We'll then explore how to run it locally and in parallel mode. Finally, I'll show you how to create a GitHub Actions workflow to automate code style checks on pull requests using PHP CS Fixer.

Installing PHP CS Fixer

To get started with PHP CS Fixer, you'll first need to install it via Composer. You can do this by running the following command in your project's root directory.

composer require friendsofphp/php-cs-fixer --dev

Create the Config File

After it finishes installing, you'll then need to create a configuration file for PHP CS Fixer. This file allows you to specify the coding standards you want to enforce, the directory you want to run the tool against, and any custom rules you may have.

To do this, you'll need to create a .php-cs-fixer.dist.php file in the root directory of your project.

Let's look at an example configuration file:

declare(strict_types=1);

use PhpCsFixer\Config;
use PhpCsFixer\Finder;

return (new Config())
    ->setRules([
        '@PSR12' => true,
    ])
    ->setFinder((new Finder())->in(__DIR__));

In the config file above, we are specifying that we want to use the PSR-12 coding standard and that we want to scan all files in the current directory (and child directories) for code style issues.

If you want to run the tool against specific directories, you can modify the setFinder method. For example, let's imagine we only want to run the tool against the src and tests directories. We can do this by updating the setFinder method as follows:

declare(strict_types=1);

use PhpCsFixer\Config;
use PhpCsFixer\Finder;

return (new Config())
    ->setRules([
        '@PSR12' => true,
    ])
    ->setFinder((new Finder())->in([
        __DIR__ . '/src',
        __DIR__ . '/tests',
    ]));

There's a ton of configuration options and rules available for PHP CS Fixer, and I won't dive into them all here. But I'd recommend checking out the documentation on GitHub so you can find any other rules you may wish to use: https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/master/doc/rules/index.rst.

Formatting Code with PHP CS Fixer

Now that we have PHP CS Fixer installed and configured, we can run it against our codebase.

Typically, there are two commands you'll want to use:

./vendor/bin/php-cs-fixer check - This command checks your code for any style issues based on the rules defined in your configuration file. It will output a list of files that do not comply with the specified coding standards.
./vendor/bin/php-cs-fixer fix - This command automatically fixes any code style issues found in your codebase based on the rules defined in your configuration file.

So if we wanted to run the check command to see if there are any code style issues in our project, we would run the following command:

vendor/bin/php-cs-fixer check

And this would generate output similar to the following:

❯ ./vendor/bin/php-cs-fixer check
PHP CS Fixer 3.89.1 Folding Bike by Fabien Potencier, Dariusz Ruminski and contributors.
PHP runtime: 8.4.2
Running analysis on 1 core sequentially.
You can enable parallel runner and speed up the analysis! Please see usage docs for more information.
Loaded config default from "/Users/ashallen/www/open-source/packages/email-utilities/.php-cs-fixer.dist.php".
Using cache file ".php-cs-fixer.cache".
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

   1) tests/Feature/Email/DomainIsNotTest.php
   2) src/Email.php

Found 2 of 20 files that can be fixed in 0.026 seconds, 20.00 MB memory used

Similarly, to automatically fix the issues found, we can run the following command:

vendor/bin/php-cs-fixer fix

Running this command would fix any of the code style issues found in our project and generate an output like so:

❯ ./vendor/bin/php-cs-fixer fix  
PHP CS Fixer 3.89.1 Folding Bike by Fabien Potencier, Dariusz Ruminski and contributors.
PHP runtime: 8.4.2
Running analysis on 1 core sequentially.
You can enable parallel runner and speed up the analysis! Please see usage docs for more information.
Loaded config default from "/Users/ashallen/www/open-source/packages/email-utilities/.php-cs-fixer.dist.php".
Using cache file ".php-cs-fixer.cache".
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

   1) tests/Feature/Email/DomainIsNotTest.php
   2) src/Email.php

Fixed 2 of 20 files in 0.029 seconds, 20.00 MB memory use

Running PHP CS Fixer in Parallel Mode

PHP CS Fixer allows running checks and fixes in parallel. This can significantly speed up the process, especially for larger codebases.

You can enable parallel mode by updating your configuration file to include the setParallelConfig method. Here's an example of how to do this:

declare(strict_types=1);

use PhpCsFixer\Config;
use PhpCsFixer\Finder;

return (new Config())
    ->setRules([
        '@PSR12' => true,
    ])
    ->setFinder((new Finder())->in(__DIR__))
    ->setParallelConfig(PhpCsFixer\Runner\Parallel\ParallelConfigFactory::detect());

In the example above, we're letting PHP CS Fixer automatically detect the optimal parallel configuration for our system. But you can manually specify these details if you wish.

Running ./vendor/bin/php-cs-fixer fix will then run the fixer in parallel mode. You should see output similar to the following:

❯ ./vendor/bin/php-cs-fixer fix  
PHP CS Fixer 3.89.1 Folding Bike by Fabien Potencier, Dariusz Ruminski and contributors.
PHP runtime: 8.4.2
Running analysis on 7 cores with 10 files per process.
Parallel runner is an experimental feature and may be unstable, use it at your own risk. Feedback highly appreciated!
Loaded config default from "/Users/ashallen/www/open-source/packages/email-utilities/.php-cs-fixer.dist.php".
Using cache file ".php-cs-fixer.cache".
 20/20 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

   1) src/Email.php

Fixed 1 of 20 files in 0.210 seconds, 20.00 MB memory used

Running PHP CS Fixer using GitHub Actions

A great way to ensure that your code style remains consistent across your team is to automate the code style checks. Doing this helps catch any instances where you forget to run the code formatter locally before pushing your changes.

To automate this process, I like to use a GitHub Actions workflow that runs on every pull request. Since PHP CS Fixer returns a non-zero exit code (indicating failure) if any code style issues are found, we can rely on this to fail the workflow.

Let's look at a typical GitHub Actions workflow you may want to use:

name: Code Style

on:
  pull_request:

jobs:
  php-cs-fixer:
    runs-on: ubuntu-latest

    steps:
      - name: Update apt
        run: sudo apt-get update --fix-missing

      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.4
          coverage: none

      - name: Install dependencies
        run: |
          composer install

      - name: Run PHP CS Fixer
        run: ./vendor/bin/php-cs-fixer check

In the example above, we can see that we're running the ./vendor/bin/php-cs-fixer check command as part of the workflow. If any code style issues are found, the command will return a non-zero exit code, causing the workflow to fail. If the command passes, it will return a zero exit code, and the workflow will succeed.

Should I Fix Issues Automatically in the Workflow?

You may want to run the fix command and automatically commit the changes to the pull request. However, I generally avoid this approach because it can introduce unexpected changes to the codebase without my knowledge. Instead, I prefer to run the check command and then fix any issues locally. This way, I have full control over the changes being made to the codebase.

This is only my personal opinion, though, and you may find that automatically fixing issues in the workflow works better for your team. If you do want to fix the issues in your workflow automatically, you might want to consider opening a pull request via your workflow with the updated code style changes instead of committing them directly to the branch. This way, you can review the changes before they are merged into the main codebase.

Conclusion

In this article, we explored how to set up and use PHP CS Fixer for maintaining code style in your PHP projects. We covered installation, configuration, running it locally and in parallel mode, and automating code style checks using GitHub Actions. By integrating PHP CS Fixer into your development workflow, you can ensure consistent code quality and adherence to coding standards across your projects.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

The Difference Between ?: and ?? in PHP

Ash Allen — Mon, 24 Nov 2025 16:30:00 +0000

Introduction

In PHP, I often see the ternary operator (?:) and null coalescing operator (??) being used interchangeably, but they actually serve different purposes.

In this article, we'll explore what both of these operators do and how they differ. We'll also look at some common gotchas that developers (myself included) have run into when using these operators.

The Ternary Operator (?:) in PHP

The ternary operator is a shorthand way of writing a ternary conditional statement.

For example, let's take a traditional if-else statement. We'll keep the examples in this article super simple purely for brevity.

Imagine we're trying to set a display name based on a provided name in a payload:

// Imagine this payload comes from an HTTP request.
$payload = [
    'name' => 'Ash',
    // ...
];

if ($payload['name']) {
    $displayName = $payload['name'];
} else {
    $displayName = 'Guest';
}

// $displayName is now set to 'Ash'

We can rewrite this using a ternary condition like so:

$payload = ['name' => 'Ash'];

$displayName = $payload['name'] ? $payload['name'] : 'Guest'; // 'Ash'

Which can then be further shortened using the ?: operator:

$payload = ['name' => 'Ash'];

$displayName = $payload['name'] ?: 'Guest'; // 'Ash'

Now let's look at some examples of what $displayName would be set to based on different values of $payload['name'].

If the payload contains a non-empty string:

$payload = ['name' => 'Ash'];

$displayName = $payload['name'] ?: 'Guest'; // 'Ash'

If the request payload contains an empty string or null:

$payload = ['name' => ''];

$displayName = $payload['name'] ?: 'Guest'; // 'Guest'

If the payload contains null:

$payload = ['name' => null];

$displayName = $payload['name'] ?: 'Guest'; // 'Guest'

If the payload contains false:

$payload = ['name' => false];

$displayName = $payload['name'] ?: 'Guest'; // 'Guest'

However, what would happen if the payload array didn't have a name key at all?

$payload = [];

$displayName = $payload['name'] ?: 'Guest';

Running the above code would result in the following exception being thrown:

ErrorException: Undefined array key "name"

So we can see that the ternary operator checks for "truthiness" of the value. If the value is falsy (such as an empty string or null), it returns the value on the right side of the operator.

However, if the variable is not set at all, it will throw an error. And this is where I often see people get confused between the ?: and ?? operators. I've seen many developers expect that the ?: operator would handle unset variables gracefully, but it does not. So let's check out the null coalescing operator next.

The Null Coalescing Operator (??) in PHP

The null coalescing operator works in a similar way to the ternary operator, but it allows us to handle unset variables without throwing an error.

Let's take our previous example and update it to use the ?? operator instead:

$payload = ['name' => 'Ash'];

$displayName = $payload['name'] ?? 'Guest'; // 'Ash'

The above code example is essentially the shorthand form of:

$payload = ['name' => 'Ash'];

$displayName = isset($payload['name']) ? $payload['name'] : 'Guest'; // 'Ash'

As we can see, we can use the ?? operator in a similar way to the ?: operator, but it's checking whether the variable is set or not, rather than checking for "truthiness".

Let's see what happens if we try to access the name key when it is not set:

$payload = [];

$displayName = $payload['name'] ?? 'Guest'; // 'Guest'

In the code example, we can see that when the name key is not set in the payload array, the ?? operator returns the value on the right side of the operator without throwing an error.

This can be really useful when working with data that's passed to you from external sources, such as API requests or user input, where you can't always guarantee that certain keys will be present.

Another key difference between the ?? and ?: operators is that the ?? operator only checks for null or unset values, whereas the ?: operator checks for "truthiness". Let's take this example:

$payload = ['name' => false];

// Using the ternary operator:
$displayName = $payload['name'] ?: 'Guest'; // 'Guest'

// Using the null coalescing operator:
$displayName = $payload['name'] ?? 'Guest'; // false

As we can see in the example above, when the name key is set to false, the ?: operator returns 'Guest', whereas the ?? operator returns false. This is something you'll want to keep in mind when deciding which operator to use.

Common Gotcha with the Null Coalescing Operator

A common gotcha I see developers run into (and have done myself many times) is accidentally hiding errors when using the ?? operator.

For example, let's say you have an API request payload that is expected to contain a first_name key, but you accidentally misspell it as frist_name:

$payload = ['first_name' => 'Ash'];

$firstName = $payload['frist_name'] ?? 'Guest'; // 'Guest'

At first glance, this code might seem okay since it doesn't throw any runtime errors. However, we will always get 'Guest' as the value of $firstName. Of course, this should typically be caught during manual and automated testing. But these things can sometimes slip through the cracks, especially in larger codebases.

Alternatively, if we had used the ternary operator instead, we would have gotten an error when trying to access the unset first_name key, which would have alerted us to the typo:

$payload = ['first_name' => 'Ash'];

$firstName = $payload['frist_name'] ?: 'Guest';

// ErrorException: Undefined array key "first_name"

Should You Use the Ternary or Null Coalescing Operator?

Both operators have valid use cases and are valuable tools in your PHP arsenal.

If you always know that a value will be available (i.e. it won't be unset), and you want to check for "truthiness", then the ternary operator (?:) is a good choice.

However, if you want to handle unset variables gracefully, or you only want to check for null or unset values, then the null coalescing operator (??) might be the better option.

As you'd imagine, the decision of which operator to use often comes down to the specific use case and the data you're working with. So you'll likely use a mixture of both operators in your codebase.

Conclusion

In this article, we've quickly explored the differences between the ?: (ternary) and ?? (null coalescing) operators in PHP.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

Black Friday 2025 - Up to 50% off my books!

Ash Allen — Mon, 24 Nov 2025 11:51:14 +0000

Hey there!

I'm going to keep this short and sweet (I know how busy our inboxes get in November from all the Black Friday deals).

This year for Black Friday, I'm offering up to 50% off my books (including the bundles, which give you even more savings):

30% off "Battle Ready Laravel"

I'm offering 30% off my book, Battle Ready Laravel.

This book is the guide to auditing, testing, fixing, and improving your Laravel applications. It has sold over 1,300 copies and is packed with a ton of actionable advice, tips, tricks, and real-life examples to help you level up your Laravel skills.

Code: 30BLACKFRIDAY2025

Get it here: https://battle-ready-laravel.com

30% off "Consuming APIs in Laravel"

I'm also offering 30% off my book, Consuming APIs in Laravel.

This book teaches you how to build awesome, robust, testable API integrations for your Laravel application using Saloon. It also breaks down complex topics such as API authentication, OAuth 2.0, API integration testing, and webhooks.

I'm always referring back to this book whenever I'm working on API integrations for my clients.

Code: 30BLACKFRIDAY2025

Get it here: https://consuming-apis-in-laravel.com

50% off "The Web Dev's Guide to Freelancing"

Finally, I'm offering 50% off my latest book, The Web Dev's Guide to Freelancing.

This book teaches you how to get started with building a successful freelancing business as a web developer. It covers everything from finding clients, setting rates, managing projects, and scaling your business.

Code: 50BLACKFRIDAY2025

Get it here: https://web-dev-freelancing.com

Immutable and Mutable Dates in PHP

Ash Allen — Thu, 20 Nov 2025 15:30:00 +0000

Introduction

When working with dates in PHP, it's important to understand the difference between mutable and immutable date objects. PHP provides two main classes for handling dates: DateTime (mutable) and DateTimeImmutable (immutable).

Similarly, if you're using the Carbon library, it also provides both mutable (Carbon\Carbon) and immutable (Carbon\CarbonImmutable) date classes.

There are some key differences between mutable and immutable date objects. And I've run into bugs more often than I'd like to admit because I didn't fully understand these differences at the time, or didn't realise which type was being used in a particular situation.

In this article, we'll explore the differences between mutable and immutable date objects in PHP and the Carbon library. We'll also look at examples of how each type behaves and explore how to use immutable date objects by default in a Laravel application.

Mutable Dates in PHP

Mutable date objects are objects which can be modified after they are created. This means that any changes made to a mutable date object will affect the original object.

For example, let's look at the following code using DateTime:

$date = new DateTime('2025-01-01');
$date->modify('+1 day');

echo $date->format('Y-m-d'); // Outputs: 2025-01-02

In this example, we've created a DateTime object representing 1st January 2025. We then called the modify method to add one day. As we can see, this changed the original $date object to represent 2nd January 2025.

The Danger of Using Mutable Dates

Since the original object is updated when copied mutable dates are updated, using them can sometimes lead to unintended side effects, particularly when passing date objects around in your code.

Let's take a look at an example, and then we'll discuss what's going on. We'll create a mutable DateTime object for 2025-01-01. We'll then create another variable that references the same DateTime object and add one day to it:

$date = new DateTime('2025-01-01');
$anotherDate = $date;

$anotherDate->modify('+1 day');

echo $date->format('Y-m-d'); // Outputs: 2025-01-02
echo $anotherDate->format('Y-m-d'); // Outputs: 2025-01-02

In the code example above, we can see that adding 1 day to $anotherDate also affects $date. This is because both variables reference the same mutable DateTime object. This can lead to bugs that are hard to track down, especially in larger codebases.

I can't tell you how many times this behaviour has bitten me in the past! I've spent hours debugging issues that were caused by unintended modifications to mutable date objects.

Typically, I've found the best approach to solving this issue is to use immutable date objects instead. However, if you must use mutable dates (maybe you're working with a large codebase that would require a lot of refactoring), you might want to consider cloning the date object before making modifications instead:

$date = new DateTime('2025-01-01');
$anotherDate = clone $date;

$anotherDate->modify('+1 day');

echo $date->format('Y-m-d'); // Outputs: 2025-01-01
echo $anotherDate->format('Y-m-d'); // Outputs: 2025-01-02

As we can see in the code example, rather than using $anotherDate = $date;, we use clone to create a copy of the original date object. This way, modifications to $anotherDate do not affect $date.

Mutable Dates in Carbon

If you're using the Carbon library for date handling, the same principles apply. Here's an example using Carbon\Carbon:

use Carbon\Carbon;

$date = Carbon::create(year: 2025, month: 1, day: 1);
$anotherDate = $date;

$anotherDate->addDay();

echo $date->toDateString(); // Outputs: 2025-01-02
echo $anotherDate->toDateString(); // Outputs: 2025-01-02

Carbon provides a handy ->copy() method to create a clone of a mutable date object:

use Carbon\Carbon;

$date = Carbon::create(year: 2025, month: 1, day: 1);
$anotherDate = $date->copy();

$anotherDate->addDay();

echo $date->toDateString(); // Outputs: 2025-01-01
echo $anotherDate->toDateString(); // Outputs: 2025-01-02

Immutable Dates in PHP

Immutable date objects are date objects that cannot be modified after they are created. Any changes made to an immutable date object will result in a new object being created, leaving the original object unchanged.

In my opinion, using immutable date objects is generally the safer and more predictable approach. I've found that it helps avoid some of the pitfalls we just discussed with mutable dates. That doesn't mean mutable dates don't have their place; they can still be helpful in certain scenarios.

You can create an immutable date object using DateTimeImmutable like this:

$date = new DateTimeImmutable('2025-01-01');

$newDate = $date->modify('+1 day');

echo $date->format('Y-m-d'); // Outputs: 2025-01-01
echo $newDate->format('Y-m-d'); // Outputs: 2025-01-02

In this code example, we created a DateTimeImmutable object for 2025-01-01. When we added a day using the modify method, it returned a new DateTimeImmutable object ($newDate) without changing the original $date object. So we avoided any unintended side effects which might catch us out later.

Immutable Dates in Carbon

If you're using the Carbon library, you can use Carbon\CarbonImmutable to create immutable date objects:

use Carbon\CarbonImmutable;

$date = CarbonImmutable::create(year: 2025, month: 1, day: 1);
$newDate = $date->addDay();

echo $date->toDateString(); // Outputs: 2025-01-01
echo $newDate->toDateString(); // Outputs: 2025-01-02

Converting Mutable Dates to Immutable Dates

There may be times when you want to convert a mutable date object to an immutable one. You can do this by using the DateTimeImmutable::createFromMutable method like so:

$mutableDate = new DateTime('2025-01-01');

$immutableDate = DateTimeImmutable::createFromMutable($mutableDate);

// Now $immutableDate is a DateTimeImmutable object

Likewise, in Carbon, you can convert a mutable Carbon\Carbon object to an immutable Carbon\CarbonImmutable object using the ->toImmutable() method:

use Carbon\Carbon;

$mutableDate = Carbon::create(year: 2025, month: 1, day: 1);
$immutableDate = $mutableDate->toImmutable();

// Now $immutableDate is a CarbonImmutable object

Using Immutable Dates by Default in Laravel

By default, when you try to get the current date using Laravel's now() helper, it will return an instance of Illuminate\Support\Carbon, which extends the mutable Carbon\Carbon class.

However, you can change this behaviour so that now() returns an instance of Carbon\CarbonImmutable instead. This will allow you to use immutable dates by default within your Laravel application. To do this, you can use the Date::use method in your App\Providers\AppServiceProvider like so:

declare(strict_types=1);

namespace App\Providers;

use Carbon\CarbonImmutable;
use Illuminate\Support\Facades\Date;
use Illuminate\Support\ServiceProvider;

final class AppServiceProvider extends ServiceProvider
{
    // ...

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Date::use(CarbonImmutable::class);
    }
}

In the code example above, we are telling Laravel to use Carbon\CarbonImmutable for all date instances created using the now() helper or any other date-related helpers provided by Laravel.

It will also ensure that any date attributes on your Eloquent models (such as created_at, updated_at) are cast to immutable date objects by default, rather than mutable ones.

Conclusion

In this article, we've explored the differences between mutable and immutable date objects in PHP and the Carbon library. We've seen how mutable date objects can lead to unintended side effects when modified, whereas immutable date objects provide a safer, more predictable approach.

If you enjoyed reading this post, you might be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

Or, you might want to check out my other 440+ page ebook "Consuming APIs in Laravel" which teaches you how to use Laravel to consume APIs from other services.

If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter.

Keep on building awesome stuff! 🚀

Saloon vs Guzzle vs SDK vs Http Facade for Laravel API Integrations

Ash Allen — Tue, 18 Nov 2025 15:20:00 +0000

The following article is a short snippet from the "Building an API Integration Using Saloon" chapter of my book "Consuming APIs In Laravel".

The book teaches you how to write powerful and robust code to build API integrations in your Laravel apps. It's packed with over **440+ pages* of actionable advice, real-life code examples, and tips and tricks.*

In the book, I teach you how to write code that can help you **sleep easy at night having confidence that your API integration works!**

What is Saloon?

Saloon is a PHP library created and maintained by Sam Carré that allows you to easily consume APIs in your PHP applications.

It uses an elegant, expressive, object-oriented approach that makes it easy to build API integrations without worrying about the underlying implementation. Saloon has many features that make it easy to build API integrations, such as authentication handling, concurrent requests, pagination, error handling, and caching.

It ships with handy default settings that make it easy for you to get started. But it also allows you to customize these settings to suit your needs.

A key benefit of Saloon is that it comes with powerful tools you can use for writing tests for your API integrations. This makes it simpler to write tests that are easy to read and maintainable.

Saloon is also an excellent choice for consuming APIs in your Laravel applications as it encourages you to abstract your code into classes, such as "connectors" and "requests", which we'll cover later in this chapter. By logically separating the code, it makes it much easier for you to maintain and extend your integrations in the future.

This chapter will focus on using Saloon v3. Specifically, we'll be using Saloon's Laravel driver, which allows us to easily integrate Saloon into our Laravel application by providing features such as:

Artisan commands for creating new connectors and request classes
Facade for mocking and recording requests for testing
Access to Laravel's HTTP sender rather than the default Guzzle sender

Alternatives to Saloon

If you're building an API integration for your Laravel application, you can take several approaches to making HTTP requests. Let's take a quick look at some of the alternatives to Saloon:

Guzzle

Guzzle is a popular PHP HTTP client that you can use to make HTTP requests. It's a great choice for making API requests, especially as it ships in the default installation of Laravel, so it doesn't require you to install any additional dependencies.

It is relatively straightforward to use and also has tools that you can use for mocking responses in your tests.

The core Saloon package actually uses Guzzle under the hood to make HTTP requests.

An example request using Guzzle may look something like this:

$client = new GuzzleHttp\Client();

$response = $client->get('https://api.github.com/user', [
    'headers' => [
        'Authorization' => 'Bearer '.config('services.github.token'),
    ]
]);

$statusCode = $response->getStatusCode();
// $statusCode is: 200

$contentType = $response->getHeader('content-type')[0];
// $contentType is: "application/json; charset=utf-8"

$contents = json_decode(
    json: $response->getBody()->getContents(),
    associative: false,
    depth: 512,
    flags: JSON_THROW_ON_ERROR
);
// $contents is: {"login": "ash-jc-allen", ...}

Http Facade

The Http facade is a class that ships with Laravel that you can use to make HTTP requests. It's a wrapper around Guzzle that simplifies some of Guzzle's functionality and makes it easier to use.

In my opinion, the Http facade provides two main benefits over using Guzzle directly:

The Http facade includes many methods you can use for testing. It allows you to mock the responses for individual calls and inspect HTTP requests to ensure your application sends them with the correct data.
All the requests made via the Http facade can be logged in Laravel Telescope (a package that provides a dashboard for debugging and inspecting your Laravel application). This makes it easy to visually inspect your requests and responses and debug any issues you may have.

As a side note, if you'd like to log your HTTP requests made by Saloon, you can install the saloonphp/laravel-http-sender package and configure Saloon to use the Http facade as the sender rather than Guzzle. We'll cover how to do this in more depth later in this chapter.

Continuing with our GitHub example from earlier, an example request using the Http facade may look something like this:

$response = Http::withToken('ghp_cK1OKarnyDda0B2nyA5eiClSE3PywM3l123')
    ->get('https://api.github.com/user');

$statusCode = $response->status();
// $statusCode is 200

$contentType = $response->header('content-type');
// $contentType is: "application/json; charset=utf-8"

$contents = $response->json();
// $contents is: {"login": "ash-jc-allen", ...}

As we can see, the Http facade hides away some of Guzzle's functionality for us to keep the code understandable and easy to read. For example, instead of needing to call getBody()->getContents() to get the response body and then using json_decode, we can simply call json() to get the response body as an array.

cURL

Another option that you can use to make HTTP requests is "Client for URL" (cURL). PHP supports libcurl, a library you can use to make different types of requests, such as HTTP requests.

In fact, Guzzle uses cURL under the hood to make HTTP requests by default because it's a powerful and flexible library that's been around for a long time and is typically available on servers. This means that when using Saloon, you're indirectly using cURL under the hood.

However, although cURL is a powerful tool, it is a lot of work to use and can be verbose. For example, take our example GitHub request and write it using cURL:

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'https://api.github.com/user');
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'Authorization: Bearer '.config('services.github.token'),
    'User-Agent: My-Laravel-App'
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$output = curl_exec($ch);

if(curl_errno($ch)){
    echo 'Curl error: ' . curl_error($ch);
} else {
    $statusCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    // $statusCode is 200

    $contentType = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);
    // $contentType is: "application/json; charset=utf-8"

    $contents = json_decode($output, false, 512, JSON_THROW_ON_ERROR);
    // $contents is: {"login": "ash-jc-allen", ...}
}

curl_close($ch);

We can see that it's a lot more verbose than the Guzzle and Http facade examples. This makes it harder to read, understand, and maintain. A general rule I like to follow when writing code is to make it read like an English sentence as much as possible. The more plain English is used, the easier it will be for new developers to understand the code, and the easier it will be for me to understand it in the future. I don't feel cURL helps achieve this goal.

You're unlikely to encounter cURL requests in your Laravel applications, but if you're working on an older application with some legacy code, you may encounter it.

API SDK

Sometimes, you must build an API integration for your Laravel application and find that the third-party service has a software development kit (SDK) available. In the context of PHP applications, an SDK is typically a Composer package you can download and install into your application that provides a wrapper around the API you're integrating.

For instance, imagine you want to interact with the Stripe API to take payments from your web application's customers. To do this, you may want to install Stripe's official PHP SDK (stripe/stripe-php). As a basic example, you could write the following code to create a new customer using the Stripe package:

use Stripe\StripeClient;

$stripe = new StripeClient(config('services.stripe.secret'));

$customer = $stripe->customers->create([
    'description' => 'John Doe',
    'email' => 'john@example.com',
    'payment_method' => 'pm_card_visa',
]);

As you can see, the SDK provides a convenient wrapper around the API, making it easy to interact with and removing the need to worry about the underlying HTTP requests and responses. This way, you can focus on the business logic of your application.

Generally, SDKs are built and maintained by the third-party service companies themselves. They act as a way to encourage developers to integrate with their API and make it as easy as possible to do so — they're essentially a marketing tool. For this reason, they're typically well-maintained and kept up to date with the latest API changes. Thus, you don't need to worry about keeping up to date with the API changes yourself, as the SDK will do this for you. You'll have the added benefit of the SDK including tests to ensure it works as expected. So, you can write your own tests to ensure that the SDK's methods are being called correctly without needing to test the underlying HTTP requests.

However, I strongly recommend inspecting an SDK before you start using it. As mentioned, these packages and libraries are a marketing tool for third-party services. As with any other aspect of business, building and maintaining them costs money. If the package isn't especially popular, it may not be well-maintained. If this is the case, you may find that the SDK is outdated and doesn't support the latest API changes. This could cause issues for your application and may mean that you must write your own wrapper around the API.

To help decide whether you should use an SDK, here are several questions to ask when inspecting it:

How many downloads does the package have? - This isn't a perfect metric, but it can give you a good idea of a package's popularity. It's likely to be well-maintained and updated if it has many downloads. It can also indicate that more people have been using it, meaning there's an increased chance bugs have been spotted and fixed. It's likely not very popular and may not be maintained very much if it has very few downloads.
How many open issues does the package have? - Check out the issues for the package and see what types of problems you're seeing. Many issues may be feature requests, which aren't necessarily alarming. The issues you want to look out for are things like "this package doesn't work with the latest version of the API" or "this package doesn't work with the latest version of PHP". These issues can indicate that the package isn't well-maintained.
How many open pull requests does the package have? - If there are open pull requests to fix bugs or add new features, this indicates community interest. Note the frequency of recent merges and whether minor fixes have been ignored for long periods to gauge maintainer activity.

Should I Use Saloon?

When planning your API integration, you might ask, "Should I use Saloon, Guzzle, the Http facade, cURL, or the API SDK?". That's a valid question you'll need to answer based on your project's needs.

Let's start by saying it's doubtful that you'll want to use cURL directly. Although it's a very powerful library, and you'll be interacting with it regardless of the other options you choose, it's not very easy to use and can be quite verbose. It's also not very easy to test compared to the other approaches, making it difficult to write tests for your application. It's important to remember that we must ensure that tests are easy to write. The easier they are to write, the more motivation you'll feel to write them. If tests are difficult to write, you'll be less likely to write them, which means you'll have less confidence in your application.

You may want to use Guzzle or the Http facade to build your integration. These are both perfectly valid approaches and ones I've used many times. They both have testing utilities and come packed with many convenient methods to simplify sending requests and reading responses. Of these two approaches, I would lean more towards the Http facade as it makes the code look cleaner and more readable — and readability is very important. If you're only going to send a single API request in your application, you may want to use one of these rather than installing Saloon. Sam Carré, the creator of Saloon, has stated in the past that it may be easier to use one of these approaches rather than installing a new dependency (Saloon) and keeping it up to date in your application.

If the third-party service you're using offers an SDK for interacting with their API, you may want to opt for that. This is, of course, assuming that it's well-maintained and that you're happy with the quality of the code. Using their package, you can take advantage of the code they've written. This will also reduce the burden of updating your code with the latest API changes.

If there isn't a well-maintained SDK available, you can use the Saloon package. Saloon allows you to use an object-oriented approach to building your integration code with small, focused classes that are highly testable. You'll also have access to Saloon features such as caching responses, error handling, OAuth handling, plugins, and more. You can take advantage of all these features to build very extensive integrations.

Another benefit of Saloon is its popularity and the fact that it's well maintained. As mentioned, it's important to ask questions before installing a new dependency in your application. You want to make sure that it's still actively being maintained and that it will be around for a long time. At the time of writing, Saloon boasts over 460k downloads (averaging at around 60k downloads per month), 1.6k stars on GitHub, and has had over 80 releases. The package also has a good-quality test suite with a high level of code coverage. These are all good indicators that the package is well maintained and is safe to use in your application.

As a side note, you can also use Saloon to build your own API SDK. You may want to do this if you're building an API service and want other developers to start using it.

No matter which of these approaches you take, I recommend writing a thin abstraction layer over your code. You can do this using interfaces and dependency injection, as we've already covered in the "Code Techniques" section. Doing this can make it easier to switch out your implementation in the future. For example, imagine you have written your API integration using an SDK that is now abandoned and won't receive any more updates. You may want to use Saloon to rewrite the API calls and logic in this situation. If the code is abstracted away behind interfaces, you'll be able to swap out the implementation without needing to change any of the code that uses the API integration. This is a very powerful technique and one that I recommend using.

Want to Continue Reading?

Hopefully, this snippet from the book has given you a good overview of Saloon and how it compares to other approaches for building API integrations in your Laravel applications.

If you've enjoyed it, you might be interested in reading the rest of the book which goes a lot more in depth about APIs and Saloon.

The book teaches you how to write powerful and robust code to build API integrations in your Laravel apps. It's packed with over 440+ pages of actionable advice, real-life code examples, and tips and tricks.

In the book, I teach you how to write code that can help you sleep easy at night having confidence that your API integration works!

👉 Make sure to use the discount code ASHALLEN20 to get 20% off!

👉 Continue Reading

Email Utilities for Laravel v1.0 Released! 🎉

Ash Allen — Mon, 17 Nov 2025 16:33:15 +0000

Introduction

A common feature I often need to build for public-facing forms is to prevent users from submitting forms with email addresses from disposable providers. These services provide temporary email addresses that can be used for a short time before being discarded.

For example, when somebody signs up for my newsletter, they receive a free copy of my "Clean Coder's Guide to Laravel" PDF. But I found that some people were using disposable email addresses to sign up, download the PDF, and then discard the email address. This meant I then had a bunch of invalid email addresses in my mailing list, which isn't ideal.

To solve this problem, in addition to using other techniques such as double opt-in and stronger email validation, I prevent users from signing up with disposable email addresses. I then found myself copying this same feature into multiple projects, so I decided to create a reusable package that I could use instead: Email Utilities for Laravel.

In this article, I'll give an overview of what the package does and how to use it in your Laravel projects.

If you're interested in checking out the package, you can find it on GitHub here: https://github.com/ash-jc-allen/email-utilities

Please note that, at the time of writing this article, this package does not validate whether an email address is valid or not. It is intended to be used in conjunction with Laravel's built-in email validation rule. This package simply provides some additional utilities for working with email addresses that I have needed in multiple projects.

Installation

To install the package, you'll need to be using at least PHP 8.3 and Laravel 11.0.

You can install the package via Composer by running the following command in your project's root directory:

composer require ashallendesign/email-utilities

After installing the package, you can then publish the configuration file using the following command:

php artisan php artisan vendor:publish --tag=email-utilities-config

Running this command will create a config/email-utilities.php file.

The "Email" Class

The package provides an AshAllenDesign\EmailUtilities\Email class for interacting with email addresses.

You can create a new instance of it by passing an email address to the constructor:

use AshAllenDesign\EmailUtilities\Email;

$email = new Email('hello@example.com');

Disposable Email Addresses

You can check whether a given email address is deemed to be disposable/temporary (meaning it's provided by a disposable email address provider) by using the isDisposable() method:

use AshAllenDesign\EmailUtilities\Email;

new Email('hello@0-mail.com')->isDisposable(); // true
new Email('hello@laravel.com')->isDisposable(); // false

The package's list of disposable domains is defined in the AshAllenDesign\EmailUtilities\Lists\DisposableDomainList class. You can output a list of all the disposable email address domains by using the get() method:

use AshAllenDesign\EmailUtilities\Lists\DisposableDomainList;

$disposableEmailDomains = DisposableEmailDomains::get();

// [
    // '0-mail.com',
    // '027168.com',
    // '062e.com',
    // ...
// ]

The list of disposable email address providers is sourced from https://github.com/disposable-email-domains/disposable-email-domains. It's worth remembering that new domains are being created all the time, so some disposable email addresses may not be detected. So please use this functionality with that in mind.

Role-based Email Addresses

You may want to check whether a given email address is role-based. Role-based email addresses are those that are not specific to an individual, but rather to a role or function within an organisation. Examples include admin@, support@, info@ and sales@.

To do this, you can use the isRoleAccount() method:

use AshAllenDesign\EmailUtilities\Email;

new Email('sales@example.com')->isRoleAccount(); // true
new Email('ash@example.com')->isRoleAccount(); // false

Similar to the disposable email address domains, the package's list of role-based email address prefixes is defined in the AshAllenDesign\EmailUtilities\Lists\RoleAccountList class. You can output a list of all the role-based email address prefixes by using the get() method:

use AshAllenDesign\EmailUtilities\Lists\RoleAccountList;

$roleAccountList = RoleAccountList::get();

// [
    // 'admin',
    // 'administrator',
    // 'contact',
    // ...
// ]

Please remember that this list is not exhaustive, so it may not detect all role-based email addresses.

Checking the Domain of an Email Address

"domainIs" Method

The AshAllenDesign\EmailUtilities\Email class also provides a domainIs method that checks whether the domain of an email address matches a given pattern. This is useful if you want to check whether an email address belongs to a specific domain or set of domains.

The beauty of this method is that it supports wildcard (*) patterns, so it allows for more flexible matching.

For example:

use AshAllenDesign\EmailUtilities\Email;

new Email('hello@example.com')->domainIs(['example.com']); // true
new Email('hello@example.com')->domainIs(['example.com', 'test.com']); // true
new Email('hello@example.com')->domainIs(['example*']); // true
new Email('hello@example.com')->domainIs(['ex*le.com']); // true
new Email('hello@example.com')->domainIs(['ex*le.com']); // true

new Email('hello@example.com')->domainIs(['example']); // false
new Email('hello@example.com')->domainIs(['test.com']); // false

"domainIsNot" Method

Similarly, the AshAllenDesign\EmailUtilities\Email class also provides a domainIsNot method, which can be used to check whether the domain of an email address does not match a given pattern.

For example:

use AshAllenDesign\EmailUtilities\Email;

new Email('hello@example.com')->domainIsNot(['example.com']); // false
new Email('hello@example.com')->domainIsNot(['example.com', 'test.com']); // false
new Email('hello@example.com')->domainIsNot(['example*']); // false
new Email('hello@example.com')->domainIsNot(['ex*le.com']); // false
new Email('hello@example.com')->domainIsNot(['ex*le.com']); // false

new Email('hello@example.com')->domainIsNot(['example']); // true
new Email('hello@example.com')->domainIsNot(['test.com']); // true

Validation Rules

Please note that the validation rules included with this package don't validate that a value is actually an email address. These rules are intended to be used in conjunction with Laravel's built-in email validation rule (https://laravel.com/docs/12.x/validation#rule-email).

"EmailDomainIs" Rule

The package provides an AshAllenDesign\EmailUtilities\Rules\EmailDomainIs validation rule that can be used to validate that the domain of an email address matches a given pattern. This is useful if you want to ensure that an email address belongs to a specific domain or set of domains, such as only allowing email addresses from your own organisation.

It uses the AshAllenDesign\EmailUtilities\Email::domainIs method under the hood, so it supports wildcard (*) patterns.

You can use the rule like so:

use AshAllenDesign\EmailUtilities\Rules\EmailDomainIs;

$request->validate([
    'email' => ['required', 'email', new EmailDomainIs(patterns: ['example.com', '*.example.com'])],
]);

In this particular example, we've hardcoded the allowed domain pattern, but you may want to load this from a configuration file or the database instead.

"EmailDomainIsNot" Rule

Similar to the EmailDomainIs rule, the package also provides an AshAllenDesign\EmailUtilities\Rules\EmailDomainIsNot validation rule that can be used to validate that the domain of an email address does not match a given pattern. This is useful if you want to ensure that an email address does not belong to a specific domain, such as a list of known disposable email address providers.

You can use the rule like so:

use AshAllenDesign\EmailUtilities\Rules\EmailDomainIsNot;

$request->validate([
    'email' => ['required', 'email', new EmailDomainIsNot(patterns: ['disposable.com', '*.disposable.com'])],
]);

This validation rule also comes with a handy disposable method so you can quickly add a rule to prevent disposable email addresses from being used:

use AshAllenDesign\EmailUtilities\Rules\EmailDomainIsNot;

$request->validate([
    'email' => ['required', 'email', EmailDomainIsNot::disposable()],
]);

Config

The package provides several options that can be configured via the published configuration file located at config/email-utilities.php.

Disposable Email Domains List

By default, the package uses a built-in list of disposable email address domains defined in the AshAllenDesign\EmailUtilities\Lists\DisposableDomainList class. Over time, this list may change as new disposable email address providers are created.

However, you can maintain your own list of disposable domains by setting the disposable_email_list_path configuration option like so:

'disposable_email_list_path' => './storage/app/disposable_email_domains.json',

You can also publish the package's built-in list to your application by running the following command:

php artisan vendor:publish --tag=email-utilities-lists

This will create a disposable-domains.json file in your application's root directory. You can then modify this file as needed and update the disposable_email_list_path configuration option to point to this file. Running this command will also publish a role-accounts.json file that you can use to maintain your own list of role-based email address prefixes.

Role Accounts List

Similar to the disposable email domains list, by default, the package uses a built-in list of role-based email address prefixes defined in the AshAllenDesign\EmailUtilities\Lists\RoleAccountList class. However, you can maintain and provide your own list by setting the role_account_list_path configuration option like so:

'role_accounts_list_path' => './storage/app/role_account_list.json',

Check Out the Package

If you're interested in checking out the package, you can find it on GitHub here: https://github.com/ash-jc-allen/email-utilities

Forem: Ash Allen

Measuring Performance with the "Benchmark" Class in Laravel

Introduction

Using the Benchmark class

Using "Benchmark::measure()"

Using "Benchmark::value()"

Using "Benchmark::dd()"

No External Tools Required

Things To Keep in Mind

Not a Replacement for Dedicated Profiling Tools

Local vs Production Benchmarking

Running Benchmarks Multiple Times

Conclusion

Reduce Duplicate Cache Queries in Laravel with "Cache::memo()"

Introduction

What is Memoisation?

Cache Memoisation with "Cache::memo()"

Using Different Cache Stores

Modifying Cache Values

Conclusion

How to Send Telegram Messages in Laravel

Introduction

Related Articles

Setting Up Your Telegram Bot

Installation

Getting the Chat ID

Sending Notifications

Sending a Location

Sending Images

Other Messages Types

On-Demand Notifications

Conclusion

Memoisation in Laravel Using the `once` Helper

Introduction

Using the "once" Helper in Laravel

Using "once" Inside Objects

Using "once" in Methods

Using "once" in Static Methods

Using "once" with Laravel Octane

Other Approaches to Memoisation in Laravel

The "Cache::memo" Method

The "array" Cache Store

Properties and Static Properties

Conclusion

Using AI to Build a Laravel Feature with Junie in PhpStorm

How AI Will Impact My Job as a Freelance Web Developer in 2026

Introduction

My Initial Thoughts

How I’ve Been Using AI

Writing Code with GitHub Copilot

Generating Code with Agents

Debugging and Fixing Issues

Writing Articles and my Books

How My Job Might Change in 2026 and Beyond

As a Freelance Web Developer

Pricing My Work

Switching from Code Writer to Code Reviewer

Fixing AI-Generated Issues

As a Content Creator

Final Thoughts

Formatting PHP Code with PHP CS Fixer

Introduction

Installing PHP CS Fixer

Create the Config File

Formatting Code with PHP CS Fixer

Running PHP CS Fixer in Parallel Mode

Running PHP CS Fixer using GitHub Actions

Should I Fix Issues Automatically in the Workflow?

Conclusion

The Difference Between ?: and ?? in PHP

Introduction

The Ternary Operator (?:) in PHP

The Null Coalescing Operator (??) in PHP

Common Gotcha with the Null Coalescing Operator

Should You Use the Ternary or Null Coalescing Operator?

Conclusion

Black Friday 2025 - Up to 50% off my books!

30% off "Battle Ready Laravel"

30% off "Consuming APIs in Laravel"

50% off "The Web Dev's Guide to Freelancing"

Using the `Benchmark` class