Phlo Realtime: WebSockets zonder de taal te verlaten

De meeste frameworks beschouwen realtime als een tweede stack die aan de eerste is bevestigd: een aparte WebSocket-server, een aparte eventbus, een apart mentaal model voor "de dingen die duwen." Phlo Realtime is in plaats daarvan gebouwd om aanvullend te zijn. Een Phlo-app is een normale request-response-app totdat de Phlo Daemon ernaast draait, en pas dan wordt de realtime-laag geactiveerd.

Eén proces, veel apps

De daemon beheert de socketverbindingen. Het is een enkel proces dat WebSocket-verbindingen multiplexeert over elke app die op de machine is geconfigureerd, en elke gebeurtenis (verbinden, ontvangen, sluiten) naar de juiste app dispatcht als een verse, schone aanroep op een worker pool. Je schrijft nooit een socketlus; je implementeert vier hooks en de daemon roept ze aan.

method wsConnect($conn) => %session->user ? true : false
method wsAuth($conn, $token) => user::record(token: $token)
method wsReceive($conn, $data) => wsCast('poll:'.$conn->room, votes: poll::tally($conn->room))
method wsClose($conn) => void

wsConnect bepaalt of een verbinding überhaupt is toegestaan. wsAuth lost op wie aan de andere kant is aan de hand van een token, als je identiteit nodig hebt. wsReceive verwerkt een binnenkomend bericht. wsClose ruimt op wanneer een client zich loskoppelt. Dit vraagt je niet om een nieuwe runtime te leren: dit zijn Phlo methoden, die worden aangeroepen zoals elke route.

Broadcasten is één oproep

De andere helft is het pushen vanuit gewone PHP. wsCast() broadcast een payload naar elke verbinding die is geabonneerd op een kanaal, vanaf overal in je app, inclusief een volledig ongerelateerde HTTP-aanroep:

method vote($option){
    poll::castVote($option)
    wsCast('poll:'.$this->room, votes: poll::tally($this->room))
}

Een normale POST /vote handler draait, werkt de database bij en duwt de nieuwe telling naar elke open tab die die peiling bekijkt, in dezelfde aanvraag. Er is geen aparte publish/subscribe client om te configureren en geen berichtformaat om uit te vinden; de daemon en de app spreken al dezelfde protocol.

Stateless by design

De worker pool van de daemon is waar de sockets zich bevinden, maar de data blijft in de database, niet in het geheugen van de daemon. Elk evenement draait als een nieuwe aanroep tegen de huidige staat, op dezelfde manier als een HTTP-aanroep zou doen. Dat houdt een moeilijk probleem volledig uit de picture: je hoeft nooit te reconciliëren "wat denkt deze langdurige verbinding dat de staat is" tegen "wat de database daadwerkelijk zegt," omdat de verbinding nooit een eigen staat vasthoudt die kan afdrijven.

Probeer het end to end

De Learn tutorial bouwt een live peiling vanaf nul in acht stappen: installeren, een route, een view, en dan precies deze vier hooks aan elkaar koppelen, eindigend in een peiling waar een stem in één tab elke andere open tab onmiddellijk bijwerkt. Het is de snelste manier om de hele cyclus te zien, verbinding te maken via broadcast, zonder eerst een specificatie te lezen.