Phoenix Is Not Your Application
summary
Claims that applications live separate from their web layer: build a pure Elixir application first, expose a clear API via an OTP application and GenServer callbacks, test it in isolation, then scaffold a Phoenix project with mix phoenix.new and add the Elixir app as a path dependency so controllers call into the running component; shows a stateful key‑value backend without Ecto, supervisors and named processes for discoverability, and replacing the web layer becomes a filesystem change not a rewrite.
AI-written summary · about
chapters (35)
- 0:00Intro
- 0:34Phoenix is not your application
- 1:31Thought experiment
- 2:16Why is it so daunting
- 3:02How we build applications
- 3:24Maintainability
- 3:45Portability
- 4:16Solution
- 4:34How does this happen
- 4:49Applications need state
- 5:00Request state
- 5:14Data access
- 5:38Domain entities
- 6:48Models
- 7:28Routers
- 7:44Decouple
- 7:54OTP Applications
- 9:28What is an application
- 10:07Application Resource File
- 11:11Hello Phoenix Module
- 12:06How does this help us
- 12:39monolith
- 13:02example application
- 13:50generate new mix application
- 14:06gen server
- 14:32client functions
- 15:04callbacks
- 15:41building
- 16:28startlink
- 20:44lastpair
- 22:16add kbb to application list
- 22:33add show action
- 23:12what have we gained
- 23:55the Phoenix Guides
- 25:00Why Phoenix
related talks
40mKeynote: The Pendulum
29mUsing Your Umbrella
47mGood behaviour: Cultivating Healthy Elixir Teams & Codebases
59mKeynote: Elixir Should Take Over the World
39mKeeping Code Consistent
06mResilient Code, Resilient Engineer: Lessons from Changing Requirements
01h 01mArchitecture Decisions: A Case Study -
33mHigh availability with Elixir and Erlang