QFM078: Elixir Reading List - August 2025
Source: Photo by Pankaj Patel on Unsplash
This month's Elixir Reading List celebrates Phoenix LiveView 1.1 and performance patterns. Phoenix LiveView 1.1 Released announces significant improvements to the framework. Why Pull-Based Pipelines Are Faster explores data pipeline design in the context of Elixir streaming.
Elixir Configuration: Environment Variables provides practical guidance on application configuration patterns.
As always, the Quantum Fax Machine Propellor Hat Key will guide your browsing. Enjoy!

Links
Elixir configuration is divided into compile-time (config.exs, dev.exs, prod.exs, test.exs) and runtime (runtime.exs) phases, where compile-time configurations are merged sequentially based on environment and cannot be changed after build, while runtime.exs allows dynamic configuration via environment variables before application startup. The configuration system originates from Erlang OTP and uses functions like Application.compile_env and Application.get_env to access values, with developers choosing between declaring configs directly in mix.exs or using the recommended separate config files approach.
Elixir's GenStage implements pull-based pipelines that prevent memory exhaustion by having downstream consumers signal demand upstream, rather than having producers push messages that may accumulate in mailboxes when processing lags. This demand propagation mechanism allows SlotProducer to saturate all CPU cores without blocking while maintaining backpressure—if downstream stages are slow (eg Kafka delivery failing), reduced demand signals upstream to halt ingestion before out-of-memory conditions occur.
Phoenix LiveView 1.1 introduces colocated hooks, allowing developers to write JavaScript hooks directly within HEEx component files using a <script :type={ Phoenix.LiveView.ColocatedHook }> tag, which the compiler automatically extracts at build time and registers via a generated manifest file. The feature also adds hook name prefixing with a leading dot (eg .Sortable) to prevent naming conflicts across the global hook namespace and enable safer library authoring. This enhancement addresses the previous friction of maintaining separate JavaScript files for small hooks that logically belong to specific components.
Regards,
M@
[ED: If you'd like to sign up for this content as an email, click here to join the mailing list.]
Originally published on quantumfaxmachine.com and cross-posted on Medium.
hello@matthewsinclair.com | matthewsinclair.com | bsky.app/@matthewsinclair.com | masto.ai/@matthewsinclair | medium.com/@matthewsinclair | xitter/@matthewsinclair
Was this useful?