Hoppa till innehåll

Fristående användning

Visa som Markdown Redigera på GitHub Dokumentation på 2cc7b2b

Queuety paketeras som ett plugin för WordPress, men det mesta av körningsmiljön behöver egentligen inte någon aktiv WordPress-begäran.

Kön, arbetsflödesmotorn, tillståndsmaskinerna, signalerna, artefakterna, batchhanteringen, schemaläggningen, loggningen, mätvärdena och resurshanteringen använder alla samma tabeller i MySQL. Om en annan PHP-process kan öppna samma databas kan den använda kärnan direkt.

Det är gränsen för fristående användning i Queuety. Den databasbaserade orkestreringsmotorn kan användas utanför WordPress. Bryggorna WordPress hör fortfarande till WordPress.

Vad som fungerar utanför WordPress

Med en direkt Connection kan en fristående process initiera Queuety och använda samma fasadmetoder som pluginet använder för kärnans körningsmiljö:

  • skicka jobb
  • köra arbetare och arbetarpooler
  • skapa och skicka iväg arbetsflöden
  • skicka signaler, godkännanden och indata till arbetsflöden
  • skapa och skicka iväg tillståndsmaskiner
  • granska status för arbetsflöden och tillståndsmaskiner
  • lagra och läsa artefakter
  • hantera batchar, kedjor och återkommande scheman
  • söka i loggar, mätvärden, köer och körningsstatus

Det innebär att en extern produkt kan kommunicera med samma orkestreringstillstånd utan att först starta WordPress, så länge den använder samma databas och tabellnamn.

Arbetarpooler är för närvarande det enda undantaget: Queuety::run_worker_pool() och Queuety::run_auto_scaling_worker_pool() läser konstanterna i WordPress DB_HOST, DB_NAME, DB_USER och DB_PASSWORD i stället för den initierade anslutningen. Därför måste en fristående process definiera dessa konstanter innan den startar en pool (#5).

Vad som hör hemma i WordPress

Brygglagret som är specifikt för WordPress är fortfarande beroende av att WordPress har lästs in.

Det omfattar:

  • pluginstart och aktiveringsbeteende i queuety.php
  • Queuety::on_action(), som kräver add_action()
  • Queuety::replace_wp_cron() och Queuety::restore_wp_cron(), som är beroende av filtren i WordPress cron och do_action()
  • den riktiga kommandoregistreringen för wp queuety ..., som är beroende av att WP-CLI läser in WordPress

De delarna är adaptrar runt kärnans körningsmiljö. De utgör inte själva körningsmiljön.

Initiering

Den fristående vägen är avsiktligt enkel. Öppna en databasbaserad Connection, initiera fasaden och kontrollera att schemat finns.

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();

Därefter är de vanliga metoderna för körningsmiljön API tillgängliga:

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();

Tabellnamn

Fristående användning kräver inte specifikt WordPress-tabellnamn. Det enda som behövs är en stabil strategi för prefix.

Om du ansluter Queuety till en WordPress-databas använder du samma prefix som pluginet använder där. Om du använder Queuety i en separat databas kan anslutningens prefix vara vad ditt värdprogram förväntar sig. Tabellprefixet som är specifikt för Queuety styrs fortfarande av QUEUETY_TABLE_PREFIX och åsidosättningarna per tabell.

Inbäddade körningsmiljöer som delar en databas kan ange den del som är specifik för Queuety per anslutning:

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

Då lämnas databasens prefix för WordPress orört och tabeller som queuety_jobs kopplas till wp_themequeue_jobs.

Tankemodell

Ett enkelt sätt att tänka på uppdelningen är:

  • kärnan i Queuety = kö, arbetare, arbetsflöden, tillståndsmaskiner, signaler, artefakter och körningsmetadata
  • adaptern för WordPress = pluginstart, bryggor för hooks, ersättning av WP-Cron och registrering av WP-CLI

På så sätt behåller du en orkestreringsmotor samtidigt som händelse- och förfrågningsintegrationen som är specifik för WordPress finns kvar där den hör hemma.