WebSocket integration is not verified end to end
triangle/engine-ws · AGPL-3.0-or-later
Engine-WS is the WebSocket application layer for Triangle. Its Composer manifest explicitly conflicts with triangle/engine-http: do not install both engines into one application and assume their shared Triangle request/response aliases are interchangeable. The Ws scaffold is a separate application template.
Triangle\Ws\App handles HTTP handshake, route dispatch, per-connection UUID/path maps and message dispatch. Triangle\Request in the WS support layer stores ws_buffer and exposes getData(). The actual connection remains Localzet TcpConnection; no Triangle\Ws\Connection class or Router\Route::ws API is provided.
A concrete mismatch remains in getCallback: it calls Middleware::getMiddleware with the old positional argument list, while the current middleware expects controller, RouteObject and withGlobal arguments. The current implementation also relies on connection/request/context lifecycle assumptions that need integrated tests. The old chat example was not executable evidence.
Before production, verify handshake rejection, authorization per channel/message, Origin policy, message schema/size limits, slow consumers, disconnect cleanup and reconnect semantics. Process-local maps do not span workers; do not scale a chat by changing count without a shared routing/state design. Use the verified low-level Server echo recipe to test transport independently; it does not validate this engine.
Direct dependencies
Section titled “Direct dependencies”| Package | Constraint |
|---|---|
php | ^8.1 |
triangle/engine | ^8.1 |
triangle/router | ^2.0 |
triangle/middleware | ^2.0 |
Pinned source · ab28668da83f.