Purchase access to watch this video.

Unlock course for £159

Already purchased access? Login

Listening for Mux webhooks

Connect GitHub

Transcript was automatically generated and may be inaccurate.

  1. We've made our video upload form a little more interactive, but our Video
  2. models won't
  3. be getting updated in the database.
  4. We added two columns to our Video model, "upload_status" and "mux_status".
  5. So we need to update these some how.
  6. To achieve this, we'll use webhooks.
  7. Webhooks is when another service pings your application with some data that the
  8. application
  9. can then respond to.
  10. Mux is no different.
  11. Mux can notify us when an upload has errored or succeeded, and also when a
  12. related asset
  13. is ready or if that too errored.
  14. Webhooks at their simplest, are just POST requests sent from another server to your
  15. application.
  16. So we can create a controller to handle webhooks sent to us from Mux.
  17. Create a MuxWwebhookController.
  18. The controller only has one purpose, so we can make it invokable.
  19. Add the new controller to our routes.
  20. Finally open the class.
  21. When you make a controller invokable, it creates a controller which has this
  22. single "__invoke" method.
  23. Mux will send webhooks as JSON requests, so we can just pass the webhook event
  24. data
  25. by passing the request body.
  26. When we json_decode the data, if we specify "true" as the second argument,
  27. that'll decode
  28. the data as an associative array, no matter if the data is an array or an
  29. object.
  30. This makes working with decoded data from JSON payloads a bit easier.
  31. So now, what events are we receiving and what does the data actually look like?
  32. At this point, Mux can't actually send any data to us, because our Sail
  33. environment
  34. is not accessible on the Internet, so Mux will be able to deliver any events to
  35. our
  36. application.
  37. Luckily, Sail has a handy "share" command that allows us to create a temporary
  38. tunnel and
  39. make our Sale-hosted website accessible on the Internet.
  40. Copy this command.
  41. Run it in the terminal window.
  42. And if we click the public HTTP address, we should see our website in the browser.
  43. This is our Sail-hosted website, but it's now available via a public URL.
  44. We can now add our webhook URL to Mux.
  45. Go to your Mux dashboard.
  46. Go to "Settings".
  47. Go to "Webhooks".
  48. Click the "Create new webhook" button, leave the environment as default.
  49. Paste your "sail share" URL.
  50. And add "/mux/webhook" to the end.
  51. Click the green "Create webhook" button.
  52. Now, any time you createm update, or delete a Mux resource, we should get a
  53. corresponding
  54. webhook sent to us to our application.
  55. We can test this by just logging anything Mux sends to us.
  56. Back in the MuxWebhookController class, simply log the payload.
  57. We'll also need to disable CSRF protection for this route.
  58. Open up your VerifyCsrfToken middleware and add an exception for our Mux
  59. webhook URL.
  60. In a new terminal window, if we tail our Laravel log file, we should see the
  61. contents of any
  62. webhooks event sent to us when we perform an operation, such as uploading a file
  63. .
  64. I've just uploaded a file, so let's see what events we actually received.
  65. The first event we received was video.upload.create.
  66. This is created when we created upload URL.
  67. Next, we received a video.asset.created event.
  68. This is sent when an asset is being created off the back of an upload, so we
  69. can assume
  70. the upload is completed at this point.
  71. Next, we received video.upload.asset_created.
  72. This is dispatched when an asset is created off the back of an upload.
  73. Finally, we received video.asset.ready.
  74. This is sent when Mux has finished processing file and the file is ready for
  75. streaming.
  76. We received this event pretty shortly after uploading, as we only created test
  77. assets
  78. that were limited to 10 seconds in length, so don't require much processing.
  79. This event will arrive much later after uploading upload if you upload and
  80. files that are much
  81. longer in duration.
  82. Using these events, we can update the upload and the Mux status of our videos.
  83. What we'll do is, set the "upload_status" to "complete" when we receive a
  84. video.asset.created
  85. event.
  86. We'll also use the video ID as a "passthrough" parameter to find the
  87. corresponding video,
  88. and also set its "mux_asset_id" and "mux_playback_id" attributes.
  89. We'll then update the "mux_status" to "ready" when we receive the video.asset.ready
  90. event.
  91. Whilst we didn't observe this event coming in, we'll also need to handle video
  92. asset
  93. error events.
  94. These are sent when processing of a video fails, so we'll later update the
  95. video's "mux_status"
  96. accordingly.
  97. If we look at a webhook payload, we can see that the event type is declared
  98. under the
  99. "type" key.
  100. We can use a PHP match statement to handle the different events we want to
  101. handle.
  102. First let's start with the "video.asset.created" event.
  103. We'll create a protected "handleVideoAssetCreated" method.
  104. And call this when the event is received, passing through the payload as a
  105. parameter.
  106. Do the same for "video.asset.ready", and "video.asset.errored".
  107. In our video.asset.created method, we now need to fetch the video by its ID and
  108. update
  109. it.
  110. We have the "passthrough" value and use Laravel "Str::afterLast" helper to get
  111. the ID.
  112. Now let's retrieve the model.
  113. And update its statuses.
  114. Set the "upload_status" to "complete".
  115. The "mux_status" to the status in the payload.
  116. And we can also set the "mux_asset_id" and "mux_playback_id".
  117. Let's also update the "mux_status" appropriately in our video.asset.ready and
  118. video.asset.error
  119. handler methods.
  120. In our ready callback, we can also set the video duration from the duration
  121. value that
  122. comes back in the payload.
  123. Now when we upload files, we should see the statuses of the video being updated
  124. in the
  125. database.
  126. When the video is ready, we should also see the duration being set.

Resources