← Async

ASYNC FEATURE

Execution Arena

Press any lane. The arena measures request timing, streams backend milestones, and makes the execution model impossible to misread.

Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

One browser action emits one backend event. Three listeners with different execution modes turn that same intent into three visibly different response lifecycles.

How it works

The page opens one SSE session, launches a mode-specific event, and then records proof from both sides: response timing from the launch request and stage-by-stage backend confirmations from the SSE stream.

Why it matters

This removes hand-wavy “Semitexa supports async” claims. The sync lane visibly blocks, the Swoole lane returns early and completes later, and the queued lane waits for a worker before finishing.

Key concepts

EventExecution::Sync
Runs the listener inline before the HTTP response is finished.
EventExecution::Async
Defers the listener with Swoole so the request can finish first.
EventExecution::Queued
Serializes the listener work into a transport for a queue worker to consume later.
SSE proof stream
A dedicated EventSource connection that receives backend stage confirmations in real time.

Proof-Driven Async Demo

One backend intent. Three execution lifecycles. Zero hand-waving.

Click any lane and watch Semitexa prove the difference between inline work, Swoole post-response work, and queue-backed background work. The response timings and SSE milestones come from the backend.

1 SSE proof stream
3 execution modes
∞ marketing ammo

Live Transport

Dedicated SSE proof stream

Connecting…

Opening one browser EventSource so every backend milestone lands in the same live audit trail.

EventSource text/event-stream session pending

Inline request

Sync

Idle

The browser waits because the listener work stays inside the request lifecycle.

Response --
Backend dispatch --
Run id 019d94fe…
100% sync listener

Backend finished all proof steps.

  • Latest completed run finished at 2026-04-16T06:33:35+00:00.

Post-response defer

Swoole Async

Idle

The response returns first. The deferred listener continues after the request is flushed.

Response --
Backend dispatch --
Run id 019e1163…
100% swoole defer

Backend finished the staged timeline.

  • Latest completed run finished at 2026-05-10T10:16:10+00:00.

Queue worker pickup

Queued Job

Idle

The request only emits a durable message. A worker finishes the side effect later.

Response --
Backend dispatch --
Run id 019e1163…
0% waiting for evidence

Ticket issued. Waiting for backend execution.

  • Waiting for the first live run.

Backend Audit Trail

The server narrates what actually happened

single live log
  • The SSE stream will append backend events here…
Queue lane requires worker bin/semitexa queue:work nats async
EventExecution::Sync EventExecution::Async EventExecution::Queued SSE proof stream

Verified against Semitexa Ultimate 2026.09.19.1020

Execution Arena

One browser action emits one backend event. Three listeners with different execution modes turn that same intent into three visibly different response lifecycles.

How it works

The page opens one SSE session, launches a mode-specific event, and then records proof from both sides: response timing from the launch request and stage-by-stage backend confirmations from the SSE stream.

Why this matters

This removes hand-wavy "Semitexa supports async" claims. The sync lane visibly blocks, the Swoole lane returns early and completes later, and the queued lane waits for a worker before finishing.

Execution modes

  • EventExecution::Sync — runs the listener inline before the HTTP response is finished.
  • EventExecution::Async — defers the listener with Swoole so the request can finish first.
  • EventExecution::Queued — serializes the listener work into a transport for a queue worker to consume later.
  • SSE proof stream — a dedicated EventSource connection that receives backend stage confirmations in real time.

© Harold Abelson: "Programs must be written for people to read, and only incidentally for machines to execute."

Event Implementation slice
<?phpdeclare(strict_types=1);namespace App\Application\Payload\Event\Example;final readonly class DemoExecutionShowcaseRequested{    public function __construct(        public string $aggregateId,        public string $actorId,    ) {}}

How it works

The page opens one SSE session, launches a mode-specific event, and then records proof from both sides: response timing from the launch request and stage-by-stage backend confirmations from the SSE stream.

Why it matters

This removes hand-wavy “Semitexa supports async” claims. The sync lane visibly blocks, the Swoole lane returns early and completes later, and the queued lane waits for a worker before finishing.

Key concepts

EventExecution::Sync
Runs the listener inline before the HTTP response is finished.
EventExecution::Async
Defers the listener with Swoole so the request can finish first.
EventExecution::Queued
Serializes the listener work into a transport for a queue worker to consume later.
SSE proof stream
A dedicated EventSource connection that receives backend stage confirmations in real time.

Support Semitexa
Built for developers who prefer control over magic. Your support helps keep it fast, open, and evolving.

Donate via PayPal