Masonite comes with a powerful way to broadcast events in your application. These events can be listened to client-side using Javascript.
These can be things like a new notification which you can show on the frontend without reloading the page.
Masonite comes with one server-side driver: Pusher.
Server side configuration for broadcasting is done in config/broadcast.py
configuration file. For now there is one driver available Pusher.
You should create an account on Pusher Channels and then create a Pusher application on your account and get the related credentials (client, app_id, secret) and the cluster location name and put this into the broadcast pusher options.
Finally make sure you install the pusher
python package
To be able to receive broadcast events in the browser you should install Javascript Pusher SDK.
Include the pusher-js script tag on your page
This is the quickest way to install Pusher. But for a real app you will often use a build system to install and compile assets and will install the Javascript Pusher SDK with npm install pusher-js
and then import Pusher class with import Pusher from 'pusher-js';
.
Create a Pusher instance configured with your credentials
It is advised to use environment variables instead of hard-coding credentials client-side. If you're using Laravel Mix to compile assets then you should prefix your environment variables with MIX_
.
Now you're ready to subscribe to channels and listen for channels events.
Broadcast events are simple classes that inherit from CanBroadcast
. You may use any class, including the Masonite Event classes.
A broadcast event will look like this:
Note that the event name emitted to the client will be the name of the class. Here it would be UserAdded
.
You can broadcast the event using the Broadcast
facade or by resolving Broadcast
class from container.
You can broadcast easily without creating a Broadcast event
Or you can broadcast the event class created earlier
You may broadcast on multiple channels as well:
This type of broadcasting will emit all channels as public. For private and presence channels, keep reading.
In this section we will use the client pusher
instance configured earlier.
To listen for events on client-side you must first subscribe to the channel the events are emitted on
Then you can listen for events
Different channel types are included in Masonite.
Inside the event class you can specify a Public channel. These channels allow anyone with a connection to listen to events on this channel:
Private channels require authorization from the user to connect to the channel. You can use this channel to emit only events that a user should listen in on.
Private channels are channels that start with a private-
prefix. When using private channels, the prefix will be prepended for you automatically.
Private channels can only be broadasting on if users are logged in. When the channel is authorized, it will check if the user is currently authenticated before it broadcasts. If the user is not authenticated it will not broadcast anything on this channel.
This will emit events on the private-channel_name
channel.
On the frontend, when you make a connection to a private channel, a POST request is triggered by the broadcast client to authenticate the private channel. Masonite ships with this authentication route for you. All you need to do is add it to your routes:
This will create a route you can authenticate you private channel on the frontend. The authorization route will be /broadcasting/authorize
but you can change this to anything you like:
Pusher is expecting the authentication route to be /pusher/user-auth
by default. If you want to change this client-side you can do it when creating Pusher instance
You will also need to add the /pusher/user-auth
route to the CSRF exemption.
The reason for this is that the broadcast client will not send the CSRF token along with the POST authorization request.
If you want to keep CSRF protection you can read more about it here.
The default behaviour is to authorize everyone to access any private channels.
If you want to customize channels authorization logic you can add your own broadcast authorization route with a custom controller. Let's imagine you want to authenticate channels per users, meaning that user with ID 1
will be able to authenticate to channel private-1
, user with ID 2
to channel private-2
and so on.
First you need to remove Broadcast.routes()
from your routes and add your own route
Then you need to create a custom controller to implement your logic
Presence channels work exactly the same as private channels except you can see who else is inside this channel. This is great for chatroom type applications.
For Presence channels, the user also has to be authenticated.
This will emit events on the presence-channel_name
channel.
Adding the authentication route is the same as for Private channels.
Authorizing channels is the same as for Private channels.
To get started more easily with event broadcasting in Masonite, two small examples are available here:
Sending public app releases notification to every users (using Public channels)
Sending private alerts to admin users (using Private channels)
To do this we need to create a NewRelease
Broadcast event and trigger this event from the backend.
On the frontend we need to listen to releases
channel and subscribe to NewRelease
events to display an alert box with the release message.
Let's imagine our User model has two roles basic
and admin
and that we want to send alerts to admin users only. The basic users should not be authorized to subscribe to the alerts.
To achieve this on the backend we need to:
create a custom authentication route to authorize admin users only on channel private-admins
create a AdminUserAlert
Broadcast event
trigger this event from the backend.
Let's first create the authentication route and controller
On the frontend we need to listen to private-admins
channel and subscribe to AdminUserAlert
events to display an alert box with the message.
You're ready to start broadcasting events in your app !