About every second or so the browser would send a request to the server to get the updated data. In a typical web application, without LiveView, common solutions are to either use websockets to push new data to client applications or have those applications poll the server. Mux is going to send webhooks to our server when relevant events happen. In the UI we show the user the streaming credentials and are now waiting for them to start streaming. Right here we have the perfect test case for LiveView. As the user, you enter those streaming credentials into your mobile app or broadcast software and start streaming. When that channel is created, Snitch will give you RTMP streaming credentials (just like Twitch does). Under the hood, of course, we’re using Mux Live Streaming.įrom the user’s perspective, first you create a “channel”. The idea I had for an example app is Snitch, it’s like “Twitch,” but for snitches (put away your checkbooks potential investors). I decided to start playing around with LiveView to see what it’s capable of. At Mux we use Phoenix and Elixir to power our API. If you’re not familiar with Phoenix, it’s the fully-featured web framework for the Elixir programming language. You can be running in minutes.Phoenix LiveView is a new experiment that allows developers to build rich, real-time user experiences with server-rendered HTML. Fly.io ❤️ Elixirįly.io is a great way to run your Phoenix LiveView app close to your users. So this solution is a good fit.īut, if we are building some report that must be generated even if the user closes the browser tab, then, this may not be the right solution. In a scenario where we're doing something that takes time and we don't save the result, we don't want the job to keep going if the user leaves. We can use _nolink/3 to make sure that our LiveView won't die even if the task crashes and that the error will be reported.Ģ) We need to think about what kind of work we want to do asynchronously. If we don't have control over the result of the task, and we don't want our LiveView to crash if the task crashes, we must use a different alternative to launch our task. Which means that both processes have a relationship: if one crashes, the other does too. José shows us this pattern in his recent video!ġ) When a task is spawned using Task.async/2, it is linked to the caller. No resources are spent on a process from which nobody expects the result anymore. We don't even have to worry if the user closes the browser tab! The process dies just like the LiveView, and the work is automatically cancelled. We use this reference to stop monitoring the task -and not receive a message if it dies-, since we received the result we needed from our task and we can discard an exit message.įinally we set the result in the assign :label to display it, and we hide our spinner by changing the content of the assign :running.Īn elegant solution, right? Just a couple lines of simple Elixir concurrency to delegate the work and limit the responsibilities of our LiveView. And Task.await/2 waits for the task's message and returns the result:ĭef handle_info ( tuple, where ref is the monitor's reference. This is possible with a couple of functions: Task.async/1 launches a process that, when it finishes its work, sends a message with the result to the caller. Sometimes we need to perform some processing asynchronously, and we need to wait for the result. The main actor is the Task module, we can use it to spawn processes to complete a specific task. How can we run async processing in a LiveView? How can we return results of an async process to the LiveView? Solution That little trick of asynchronously working in the background while being handled all from the server was just so elegantly simple and clean that it deserves a deeper look! Problem Once the processing is done, the indicator disappears and the results are printed on the screen: This means the user is not blocked and can still interact with the page while the process chugs away performing the work. The example works like this: You upload an image and the process for classifying images with Bumblebee runs in an asynchronous process while a small working indicator is shown. We can see all the parts together in one place, and run the example just with a single command… it must be said, it's impressive! Last month Chris McCord developed an amazing single-file example for doing image classification using Bumblebee, Nx and LiveView. Fly.io is a great place to run your Elixir applications! Check out how to get started! In this post we talk about how to perform async processing from a LiveView using easy Elixir concurrency. 4 min Share this post on Twitter Share this post on Hacker News Share this post on Reddit Async Processing in LiveView Author Name Berenice Medel Social Media View Twitter Profile Image by Annie Ruygt.
0 Comments
Leave a Reply. |