Listening for Mux webhooks
-
–
We've made our video upload form a little more interactive, but our Video -
–
models won't -
–
be getting updated in the database. -
–
We added two columns to our Video model, "upload_status" and "mux_status". -
–
So we need to update these some how. -
–
To achieve this, we'll use webhooks. -
–
Webhooks is when another service pings your application with some data that the -
–
application -
–
can then respond to. -
–
Mux is no different. -
–
Mux can notify us when an upload has errored or succeeded, and also when a -
–
related asset -
–
is ready or if that too errored. -
–
Webhooks at their simplest, are just POST requests sent from another server to your -
–
application. -
–
So we can create a controller to handle webhooks sent to us from Mux. -
–
Create a MuxWwebhookController. -
–
The controller only has one purpose, so we can make it invokable. -
–
Add the new controller to our routes. -
–
Finally open the class. -
–
When you make a controller invokable, it creates a controller which has this -
–
single "__invoke" method. -
–
Mux will send webhooks as JSON requests, so we can just pass the webhook event -
–
data -
–
by passing the request body. -
–
When we json_decode the data, if we specify "true" as the second argument, -
–
that'll decode -
–
the data as an associative array, no matter if the data is an array or an -
–
object. -
–
This makes working with decoded data from JSON payloads a bit easier. -
–
So now, what events are we receiving and what does the data actually look like? -
–
At this point, Mux can't actually send any data to us, because our Sail -
–
environment -
–
is not accessible on the Internet, so Mux will be able to deliver any events to -
–
our -
–
application. -
–
Luckily, Sail has a handy "share" command that allows us to create a temporary -
–
tunnel and -
–
make our Sale-hosted website accessible on the Internet. -
–
Copy this command. -
–
Run it in the terminal window. -
–
And if we click the public HTTP address, we should see our website in the browser. -
–
This is our Sail-hosted website, but it's now available via a public URL. -
–
We can now add our webhook URL to Mux. -
–
Go to your Mux dashboard. -
–
Go to "Settings". -
–
Go to "Webhooks". -
–
Click the "Create new webhook" button, leave the environment as default. -
–
Paste your "sail share" URL. -
–
And add "/mux/webhook" to the end. -
–
Click the green "Create webhook" button. -
–
Now, any time you createm update, or delete a Mux resource, we should get a -
–
corresponding -
–
webhook sent to us to our application. -
–
We can test this by just logging anything Mux sends to us. -
–
Back in the MuxWebhookController class, simply log the payload. -
–
We'll also need to disable CSRF protection for this route. -
–
Open up your VerifyCsrfToken middleware and add an exception for our Mux -
–
webhook URL. -
–
In a new terminal window, if we tail our Laravel log file, we should see the -
–
contents of any -
–
webhooks event sent to us when we perform an operation, such as uploading a file -
–
. -
–
I've just uploaded a file, so let's see what events we actually received. -
–
The first event we received was video.upload.create. -
–
This is created when we created upload URL. -
–
Next, we received a video.asset.created event. -
–
This is sent when an asset is being created off the back of an upload, so we -
–
can assume -
–
the upload is completed at this point. -
–
Next, we received video.upload.asset_created. -
–
This is dispatched when an asset is created off the back of an upload. -
–
Finally, we received video.asset.ready. -
–
This is sent when Mux has finished processing file and the file is ready for -
–
streaming. -
–
We received this event pretty shortly after uploading, as we only created test -
–
assets -
–
that were limited to 10 seconds in length, so don't require much processing. -
–
This event will arrive much later after uploading upload if you upload and -
–
files that are much -
–
longer in duration. -
–
Using these events, we can update the upload and the Mux status of our videos. -
–
What we'll do is, set the "upload_status" to "complete" when we receive a -
–
video.asset.created -
–
event. -
–
We'll also use the video ID as a "passthrough" parameter to find the -
–
corresponding video, -
–
and also set its "mux_asset_id" and "mux_playback_id" attributes. -
–
We'll then update the "mux_status" to "ready" when we receive the video.asset.ready -
–
event. -
–
Whilst we didn't observe this event coming in, we'll also need to handle video -
–
asset -
–
error events. -
–
These are sent when processing of a video fails, so we'll later update the -
–
video's "mux_status" -
–
accordingly. -
–
If we look at a webhook payload, we can see that the event type is declared -
–
under the -
–
"type" key. -
–
We can use a PHP match statement to handle the different events we want to -
–
handle. -
–
First let's start with the "video.asset.created" event. -
–
We'll create a protected "handleVideoAssetCreated" method. -
–
And call this when the event is received, passing through the payload as a -
–
parameter. -
–
Do the same for "video.asset.ready", and "video.asset.errored". -
–
In our video.asset.created method, we now need to fetch the video by its ID and -
–
update -
–
it. -
–
We have the "passthrough" value and use Laravel "Str::afterLast" helper to get -
–
the ID. -
–
Now let's retrieve the model. -
–
And update its statuses. -
–
Set the "upload_status" to "complete". -
–
The "mux_status" to the status in the payload. -
–
And we can also set the "mux_asset_id" and "mux_playback_id". -
–
Let's also update the "mux_status" appropriately in our video.asset.ready and -
–
video.asset.error -
–
handler methods. -
–
In our ready callback, we can also set the video duration from the duration -
–
value that -
–
comes back in the payload. -
–
Now when we upload files, we should see the statuses of the video being updated -
–
in the -
–
database. -
–
When the video is ready, we should also see the duration being set.