5 ways to INSTANTLY make BETTER VIDEOS! - YouTube
A systematic guide to evolving async task handling in Phoenix LiveView from broken (10-minute UI locks) to polished, using task supervisors, PubSub, and persistence—with specific patterns that work even when assign_async can't help.
Read Original Summary used for search
TLDR
• Real case study: Meal planning SaaS with 7 sequential GPT-4 API calls created 5-10 minute UI locks where users couldn't tell if anything was happening
• The 30-second LiveView timeout: handle_event callbacks that don't respond within 30 seconds crash the LiveView—you must respond immediately and process async
• Task.Supervisor.async_no_link vs Task.async: Use supervised tasks to decouple from LiveView process lifecycle, so work continues even if user refreshes
• PubSub pattern: Subscribe LiveView to topics in mount, broadcast when async tasks complete—enables real-time updates regardless of which process kicked off the work
• The assign_async limitation: Phoenix's new primitive won't keep tasks running if LiveView closes, so these patterns still matter for long-running work
In Detail
The talk presents a systematic evolution from broken to polished async task handling in Phoenix LiveView, based on building a meal planning SaaS that made 7 sequential GPT-4 API calls (5-10 minutes total). The core problem: synchronous execution locked the UI completely, users had no feedback, and LiveView's 30-second timeout on handle_event callbacks would crash the application for long-running tasks.
The solution progresses through five implementations, each solving a specific failure mode. First, using Task.async unlocks the UI and shows loading states, but data is lost on page refresh since the task is linked to the LiveView process. Adding database persistence solves data loss, but requires switching to Task.Supervisor.async_no_link to decouple tasks from the LiveView lifecycle—this means manually tracking caller PIDs and sending results back. The final piece is PubSub: subscribe to topics in LiveView mount and broadcast when tasks complete, enabling real-time updates even if the user refreshes mid-task. The pattern also requires explicit error handling (pattern match on failures, show flash messages) and can be polished with CSS animations triggered by push_event.
The critical insight is that Phoenix's new assign_async primitive won't solve tasks that need to survive LiveView process death—it handles tasks on exit. For expensive, long-running work (API calls that cost tokens, database queries users paid for), you need task supervisors, persistence, and PubSub to ensure work continues and users stay informed regardless of page state. The talk emphasizes UX psychology: 3-second waits feel like 10 seconds, and graceless async handling directly impacts conversion rates and user retention.