Waarom we voor realtime-projecten naar Phoenix en Elixir grijpen

De meeste teams behandelen realtime als een feature flag. Je bouwt het product op een gewone stack en plakt er een WebSocket-laag op zodra de klant om live updates vraagt. Die WebSocket-laag is half kapot, de rest van de codebase heeft geen mening over concurrency, en elke realtime-feature vraagt om een ervaren ontwikkelaar als oppas.

Phoenix en Elixir draaien dat om. Realtime is het fundament, niet een feature. De BEAM (de virtuele machine van Erlang) is in de jaren tachtig gebouwd om telefooncentrales te draaien: miljoenen gelijktijdige verbindingen, gesuperviseerde process trees, hot code reload, fouttolerantie als eerste prioriteit. Phoenix is wat je krijgt als een stel compiler-nerds zo'n runtime erft en er een web framework op schrijft.

Voor de realtime-workloads die we het vaakst opleveren, operator-dashboards met honderden live databronnen, tools om samen aan documenten te werken, multi-tenant SaaS met presence, is Phoenix juist het duurst om níét te gebruiken.

Wat Phoenix je geeft dat de reflex-stack niet biedt

De standaard Node-, Python- of Ruby-stack behandelt elk verzoek als een request-response cyclus. Concurrency is een library: je grijpt naar een queue (BullMQ, Sidekiq, Celery), een pub/sub-systeem (Redis, NATS), een WebSocket-server (Socket.io, ws), en een presence-tracker die je zelf schrijft. Elk onderdeel maakt de operatie groter. Elk heeft zijn eigen manier om stuk te gaan.

Phoenix vouwt dat in het framework zelf:

• Channels. In twee richtingen, multi-topic, automatische reconnect. Op de draad dezelfde vorm als WebSockets, maar met backpressure, broadcast en per-channel auth als ingebouwde primitieven.
• PubSub. Een ingebouwd fan-out systeem dat horizontaal schaalt zonder Redis. 10.000 luisteraars op één bericht is één aanroep van `Phoenix.PubSub.broadcast/3`.
• Presence. Het lastige probleem 'wie is er nu online' opgelost met een CRDT eronder. Gedeelde cursors, room membership, join/leave events: standaard meegeleverd.
• OTP-supervisie. Elk process staat onder supervisie. Een crashende websocket-handler trekt de connection pool niet onderuit. Een buggy GenServer trekt de applicatie niet onderuit. De runtime herstart het kapotte stuk.

Wanneer het wint

Drie workloads waar Phoenix elk alternatief verslaat dat we hebben geprobeerd.

• Operator-dashboards met hoge data-fanout. Eén server die dezelfde delta naar 5.000 verbonden operationele bedrijven pusht. Phoenix gebruikt in rust ongeveer 1GB RAM. De vergelijkbare Node + Redis-opstelling is drie machines en een coördinatielaag.
• Apps waar meerdere gebruikers samenwerken. Gedeelde cursors, presence-indicatoren, conflict-vrije updates. Het stateful, server-rendered model van LiveView handelt dit af zonder de combinatie van SPA plus state library.
• Per-tenant duurzame state. Een GenServer per tenant met game state, een inference queue, een billing meter, onder supervisie, herstartbaar, in-process. De Erlang Distribution laat dit werken over een cluster zonder dat je de code hoeft aan te passen.

Wanneer het verliest

Drie patronen waar we naar iets anders grijpen.

• Producten die in de eerste plaats native mobiel zijn. Phoenix helpt je niet bij het schrijven van de iOS-app. Je hebt nog steeds het SPA-achtige API-endpoint nodig dat de mobiele client aanspreekt.
• Anonieme publieke oppervlakken met extreme performance-budgets. Een landing page met veel verkeer, een read API die je via de CDN kunt cachen. Elixir is snel, maar Rust aan de edge is sneller, en een statische site is gratis.
• Teams die geen Elixir-onderhouder vasthouden. Senior Elixir-ontwikkelaars vinden is lastiger dan senior TypeScript-ontwikkelaars vinden. Kijkt niemand meer actief naar de codebase om, dan is de Erlang-stack die je niet kunt lezen duurder dan de Node-stack die je wel kunt lezen.