3: De dispatch API

De hoofd-eindpunt van de daemon is POST /dispatch. Het bindt standaard 127.0.0.1, dus het is alleen lokaal; beveilig het aan de netwerkgrens.

3.1: Routeren: op app-pad

Een dispatch bevat {app, target, args?, stream?, async?}: het absolute .../app.php pad vertelt de daemon welke app moet worden uitgevoerd, en de pool van elke app is gekoppeld aan dat pad. De runtime helpers (geactiveerd door de daemon constante) kennen hun eigen app en dispatchen direct; er is geen hostmap om te raadplegen.

De ingebouwde WebSocket-server (Phlo Realtime) gaat niet via /dispatch. Het kent alleen de Host header van een verbinding, dus het koppelt dat aan een app via het register, dat is gevuld vanuit de hosts map in config/daemon.js, en dispatcht vervolgens het websocket::<hook> doel in-process op dezelfde pool. POST /message (de broadcast bridge) en GET /health completeren de API.

3.2: Sync, async, stream

Dezelfde eindpunt antwoordt in drie vormen:

Verzoek Antwoord
default {status:"ok", result} zodra de oproep terugkeert
async: true 202 {status:"ok", queued:true} onmiddellijk; de oproep wordt fire-and-forget uitgevoerd op de pool
stream: true een application/x-ndjson stream van {t:line,data}* dan {t:done,result} of {t:error}

Streaming is hoe progressieve output (een Phlo Realtime receive handler, een AI token stream) regel voor regel terugvloeit terwijl de worker het afdrukt.

3.3: Wat komt terug

De pool retourneert de werkelijke retourwaarde van het doel, getypeerd (een boolean blijft een boolean). De one-shot fallback retourneert de stdout van het proces als een string, zodat een consument die op het resultaat takken beide vormen kan afhandelen. Fouten verschijnen als een afgewezen dispatch (HTTP-fout voor sync, een {t:error} frame voor streams), wat is hoe een gegooide handler een geweigerde WebSocket-handshake wordt.

We gebruiken essentiële cookies om deze site te laten werken. Met uw toestemming gebruiken we ook analytics om de site te verbeteren.