For Existing OpenSwoole Server

This implementation is about the basic usage of Socket Conveyor, without the Conveyor Server.

The basic usage

Conveyor processes every incoming message at the “message” event of the WebSocket server. For that, do as follows:

<?php

use OpenSwoole\WebSocket\Server;
use OpenSwoole\WebSocket\Frame;
use Conveyor\ConveyorServer;

$websocket = new Server('0.0.0.0', 8080);
$websocket->on('message', fn (Server $server, Frame $frame) => 
    Conveyor::init()
        ->server($server)
        ->fd($frame->fd)
        ->run($frame->data));
$websocket->on('request', fn(Request $rq, Response $rp) => $rp->end($html));
$websocket->start();

This solution will handle every incoming message and process it, providing all Socket Conveyor’s features. Thats it!

The Workflow

When using Socket Conveyor within an existing OpenSwoole server, you need to pay attention to its workflow. Socket Conveyor has a Workflow to make sure a sequence of pieces are in place at any given moment. This is a part that os always evolving, so having some visualizable structure makes the work easier.

Here is a diagram of the workflow in place:

This diagram represents the Workflow implemented in Socket Conveyor. This workflow happens in chain in the code, we will check that later. For now, let’s see the list of functions that the developer has access to in the actual usage of this class to accomplish the workflow:

Full example:

<?php

Conveyor\Conveyor::init()
    ->server($server)
    ->fd($fd)
    // here we replace any default persistence in Conveyor (must implement ConveyorPersistenceInterfacesGenericPersistenceInterface)
    ->persistence()
    // here we add extra actions (must implement ConveyorActionsInterfacesActionInterface)
    ->addActions([new SampleAction()])
    // here we add middlewares to actions (must be callables)
    ->addMiddlewareToAction(SampleAction::NAME, new SampleMiddleware())
    ->run(json_encode([
        'action' => SampleAction::NAME,
        'token'  => 'invalid-token',
        'second-verification'  => 'valid',
    ]));

Explanation:

1. Function:server
   • Dependencies: Starts from the started state.
   • Next State: Transitions to the server_set state.
2. Function:fd
   • Dependencies: Starts from the server_set state.
   • Next State: Transitions to the fd_set state.
3. Function:persistence
   • Dependencies: Can start from any of the following states:
     • fd_set
     • actions_added
     • middleware_added
   • Next State: Transitions to the persistence_set state.
4. Function:addActions
   • Dependencies: Can start from any of the following states:
     • fd_set
     • persistence_set
     • middleware_added
     • actions_added (self-transition)
   • Next State: Transitions to the actions_added state.
5. Function:addMiddlewareToAction
   • Dependencies: Can start from any of the following states:
     • fd_set
     • persistence_set
     • actions_added
     • middleware_added (self-transition)
   • Next State: Transitions to the middleware_added state.
6. Function:run
   • Dependencies: Can start from any of the following states:
     • persistence_set
     • actions_added
     • middleware_added
   • Next State: Transitions to the action_prepared state.

At this stage, there is a sequence of transitions that happens without functions:

1. Transition:prepare_pipeline
   • Dependencies: Starts from the action_prepared state.
   • Next State: Transitions to the pipeline_prepared state.
2. Transition:process_message
   • Dependencies: Starts from the pipeline_prepared state.
   • Next State: Transitions to the message_processed state.
3. Transition:finalize
   • Dependencies: Starts from the message_processed state.
   • Next State: Transitions to the finalized state.

Each function represents a transition in the workflow, and then, the final few transitions happen after the “run” function call. This documentation can serve as a guide for understanding the flow and dependencies of the system.