単独での使用

Markdownとして表示 GitHubで編集ドキュメント: 2cc7b2b

QueuetyはWordPressプラグインとしてパッケージ化されていますが、実行時機能の大半は、実行中のWordPressリクエストを実際には必要としません。

キュー、ワークフローエンジン、状態マシン、シグナル、アーティファクト、バッチ処理、スケジューリング、ログ、メトリクス、リソース管理はすべて、同じMySQLテーブルを使って動作します。別のPHPプロセスから同じデータベースを開けるなら、そのコアを直接利用できます。

これがQueuetyにおける単独利用の境界です。データベースベースのオーケストレーションエンジンはWordPressの外でも使えます。WordPressブリッジは引き続きWordPressに属します。

WordPressの外で使える機能

直接Connectionを使うと、独立したプロセスでQueuetyを初期化し、プラグインがコアランタイムで使用するものと同じファサードメソッドを利用できます。

ジョブをディスパッチする
ワーカーとワーカープールを実行する
ワークフローを構築してディスパッチする
シグナル、承認、ワークフロー入力を送信する
状態マシンを構築してディスパッチする
ワークフローとマシンの状態を確認する
アーティファクトを保存して読み取る
バッチ処理、チェーン処理、定期スケジュールを実行する
ログ、メトリクス、キュー、実行時状態を照会する

つまり、外部の製品から、先にWordPressを起動せずに同じオーケストレーション状態へアクセスできます。ただし、同じデータベースとテーブル名を使用する必要があります。

ワーカープールは現時点で唯一の例外です。Queuety::run_worker_pool()とQueuety::run_auto_scaling_worker_pool()は初期化済みの接続ではなく、WordPress DB_HOST、DB_NAME、DB_USER、DB_PASSWORD定数を読み取ります。そのため、単独プロセスではプールの起動前にこれらの定数を定義する必要があります（#5）。

WordPress内にとどまる機能

WordPress固有のブリッジ層は、引き続きWordPressが読み込まれていることに依存します。

対象には次が含まれます。

queuety.phpでのプラグイン初期化と有効化の動作
Queuety::on_action()。add_action()が必要です
Queuety::replace_wp_cron()とQueuety::restore_wp_cron()。WordPress cronフィルターとdo_action()に依存します
実際のwp queuety ...コマンド登録経路。WP-CLIがWordPressを読み込む必要があります

これらはコア実行環境を囲むアダプターであり、実行環境そのものではありません。

初期化

単独利用の手順は意図的に簡潔です。データベース対応のConnectionを開き、ファサードを初期化して、スキーマが存在することを確認します。

PHP

use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();

その後、通常の実行時APIを利用できます。

PHP

Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();

テーブル名

単独利用では、WordPress固有のテーブル名は必要ありません。安定したプレフィックス戦略があれば十分です。

QueuetyをWordPressデータベースに接続する場合は、そこでプラグインが使うものと同じプレフィックスを使います。別のデータベースでQueuetyを使う場合、接続プレフィックスはホストアプリケーションに合わせて設定できます。Queuety固有のテーブル部分は、引き続きQUEUETY_TABLE_PREFIXとテーブルごとの上書き設定によって制御されます。

1つのデータベースを共有する組み込み実行環境では、接続ごとにQueuety固有の部分を設定できます。

PHP

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);

これにより、WordPressのデータベースプレフィックスはそのままに、queuety_jobsなどのテーブル名をwp_themequeue_jobsとして解決できます。

考え方

この分割は次のように考えると分かりやすくなります。

Queuetyコア = キュー、ワーカー、ワークフロー、状態マシン、シグナル、アーティファクト、実行時メタデータ
WordPressアダプター = プラグイン初期化、フックブリッジ、WP-Cronの置き換え、WP-CLI登録

これにより、オーケストレーションエンジンを1つに保ちながら、WordPress固有のイベント連携とリクエスト連携を適切な場所に置けます。