Notifications
Introduction
In addition to support for sending email, Laravel provides support for sending notifications across a variety of delivery channels, including email, SMS (via Vonage, formerly known as Nexmo), and Slack. In addition, a variety of community built notification channels have been created to send notification over dozens of different channels! Notifications may also be stored in a database so they may be displayed in your web interface.
Typically, notifications should be short, informational messages that notify users of something that occurred in your application. For example, if you are writing a billing application, you might send an "Invoice Paid" notification to your users via the email and SMS channels.
Generating Notifications
In Laravel, each notification is represented by a single class that is typically stored in the app/Notifications
directory. Don't worry if you don't see this directory in your application - it will be created for you when you run the make:notification
Artisan command:
php artisan make:notification InvoicePaid
This command will place a fresh notification class in your app/Notifications
directory. Each notification class contains a via
method and a variable number of message building methods, such as toMail
or toDatabase
, that convert the notification to a message tailored for that particular channel.
Sending Notifications
Using The Notifiable Trait
Notifications may be sent in two ways: using the notify
method of the Notifiable
trait or using the Notification
facade. The Notifiable
trait is included on your application's App\Models\User
model by default:
<?php
namespace App\Models;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
class User extends Authenticatable
{
use Notifiable;
}
The notify
method that is provided by this trait expects to receive a notification instance:
use App\Notifications\InvoicePaid;
$user->notify(new InvoicePaid($invoice));
Remember, you may use the Notifiable
trait on any of your models. You are not limited to only including it on your User
model.
Using The Notification Facade
Alternatively, you may send notifications via the Notification
facade. This approach is useful when you need to send a notification to multiple notifiable entities such as a collection of users. To send notifications using the facade, pass all of the notifiable entities and the notification instance to the send
method:
use Illuminate\Support\Facades\Notification;
Notification::send($users, new InvoicePaid($invoice));
You can also send notifications immediately using the sendNow
method. This method will send the notification immediately even if the notification implements the ShouldQueue
interface:
Notification::sendNow($developers, new DeploymentCompleted($deployment));
Specifying Delivery Channels
Every notification class has a via
method that determines on which channels the notification will be delivered. Notifications may be sent on the mail
, database
, broadcast
, nexmo
, and slack
channels.
If you would like to use other delivery channels such as Telegram or Pusher, check out the community driven Laravel Notification Channels website.
The via
method receives a $notifiable
instance, which will be an instance of the class to which the notification is being sent. You may use $notifiable
to determine which channels the notification should be delivered on:
/**
* Get the notification's delivery channels.
*
* @param mixed $notifiable
* @return array
*/
public function via($notifiable)
{
return $notifiable->prefers_sms ? ['nexmo'] : ['mail', 'database'];
}
Queueing Notifications
Before queueing notifications you should configure your queue and start a worker.
Sending notifications can take time, especially if the channel needs to make an external API call to deliver the notification. To speed up your application's response time, let your notification be queued by adding the ShouldQueue
interface and Queueable
trait to your class. The interface and trait are already imported for all notifications generated using the make:notification
command, so you may immediately add them to your notification class:
<?php
namespace App\Notifications;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Notification;
class InvoicePaid extends Notification implements ShouldQueue
{
use Queueable;
// ...
}
Once the ShouldQueue
interface has been added to your notification, you may send the notification like normal. Laravel will detect the ShouldQueue
interface on the class and automatically queue the delivery of the notification:
$user->notify(new InvoicePaid($invoice));
If you would like to delay the delivery of the notification, you may chain the delay
method onto your notification instantiation:
$delay = now()->addMinutes(10);
$user->notify((new InvoicePaid($invoice))->delay($delay));
You may pass an array to the delay
method to specify the delay amount for specific channels:
$user->notify((new InvoicePaid($invoice))->delay([
'mail' => now()->addMinutes(5),
'sms' => now()->addMinutes(10),
]));
When queueing notifications, a queued job will be created for each recipient and channel combination. For example, six jobs will be dispatched to the queue if your notification has three recipients and two channels.
Customizing The Notification Queue Connection
By default, queued notifications will be queued using your application's default queue connection. If you would like to specify a different connection that should be used for a particular notification, you may define a $connection
property on the notification class:
/**
* The name of the queue connection to use when queueing the notification.
*
* @var string
*/
public $connection = 'redis';
Customizing Notification Channel Queues
If you would like to specify a specific queue that should be used for each notification channel supported by the notification, you may define a viaQueues
method on your notification. This method should return an array of channel name / queue name pairs:
/**
* Determine which queues should be used for each notification channel.
*
* @return array
*/
public function viaQueues()
{
return [
'mail' => 'mail-queue',
'slack' => 'slack-queue',
];
}
Queued Notifications & Database Transactions
When queued notifications are dispatched within database transactions, they may be processed by the queue before the database transaction has committed. When this happens, any updates you have made to models or database records during the database transaction may not yet be reflected in the database. In addition, any models or database records created within the transaction may not exist in the database. If your notification depends on these models, unexpected errors can occur when the job that sends the queued notification is processed.
If your queue connection's after_commit
configuration option is set to false
, you may still indicate that a particular queued notification should be dispatched after all open database transactions have been committed by calling the afterCommit
method when sending the notification:
use App\Notifications\InvoicePaid;
$user->notify((new InvoicePaid($invoice))->afterCommit());