Gå til indhold

Selvstændig brug

Vis som Markdown Rediger på GitHub Dokumentation hos 2cc7b2b

Queuety er pakket som et WordPress-plugin, men det meste af runtime-miljøet har faktisk ikke brug for en aktiv WordPress-forespørgsel.

Køen, workflow-motoren, tilstandsmaskinerne, signalerne, artefakterne, batchbehandlingen, planlægningen, logningen, målingerne og ressourcestyringen kører alle mod de samme MySQL-tabeller. Hvis en anden PHP-proces kan åbne den samme database, kan den bruge denne kerne direkte.

Det er grænsen for selvstændig brug i Queuety. Den databasebaserede orkestreringsmotor kan bruges uden for WordPress. Broerne til WordPress hører stadig til i WordPress.

Hvad fungerer uden for WordPress

Med en direkte Connection kan en selvstændig proces initialisere Queuety og bruge de samme facade-metoder som pluginet til kernens runtime-miljø:

  • afsend jobs
  • kør workers og worker-pools
  • opbyg og afsend workflows
  • send signaler, godkendelser og workflow-input
  • opbyg og afsend tilstandsmaskiner
  • undersøg status for workflows og maskiner
  • gem og læs artefakter
  • styr batchbehandling, kædning og tilbagevendende tidsplaner
  • forespørg på logfiler, målinger, køer og runtime-status

Det betyder, at et eksternt produkt kan tilgå den samme orkestreringstilstand uden først at starte WordPress, så længe det bruger den samme database og de samme tabelnavne.

Worker-pools er den eneste undtagelse i øjeblikket: Queuety::run_worker_pool() og Queuety::run_auto_scaling_worker_pool() læser konstanterne WordPress DB_HOST, DB_NAME, DB_USER og DB_PASSWORD i stedet for den initialiserede forbindelse, så en selvstændig proces skal definere disse konstanter, før den starter en pool (#5).

Hvad forbliver i WordPress

Bro-laget, der er specifikt for WordPress, afhænger stadig af, at WordPress er indlæst.

Det omfatter:

  • plugin-opstart og aktiveringsadfærd i queuety.php
  • Queuety::on_action(), som kræver add_action()
  • Queuety::replace_wp_cron() og Queuety::restore_wp_cron(), som afhænger af filtrene WordPress cron og do_action()
  • den egentlige kommandoregistreringssti for wp queuety ..., som afhænger af, at WP-CLI indlæser WordPress

Disse dele er adaptere omkring kernens runtime-miljø. De er ikke selve runtime-miljøet.

Initialisering

Den selvstændige sti er bevidst enkel. Åbn en DB-baseret Connection, initialiser facaden, og sørg for, at skemaet findes.

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

Derefter er den normale runtime-API tilgængelig:

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

Tabelnavngivning

Selvstændig brug kræver ikke specifikt tabelnavne fra WordPress. Den kræver blot en stabil præfiksstrategi.

Hvis du peger Queuety mod en WordPress-database, skal du bruge det samme præfiks, som pluginet bruger dér. Hvis du bruger Queuety i en separat database, kan forbindelsespræfikset være det, din værtsapplikation forventer. Den tabeldel, der er specifik for Queuety, styres stadig af QUEUETY_TABLE_PREFIX og tilsidesættelserne for de enkelte tabeller.

Indlejrede runtime-miljøer, der deler én database, kan angive denne Queuety-specifikke del for hver forbindelse:

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

Det lader databasepræfikset fra WordPress være urørt og oversætter tabelnavne som queuety_jobs til wp_themequeue_jobs.

Mental model

Den enkleste måde at forstå opdelingen på er:

  • Queuety-kerne = kø, workers, workflows, tilstandsmaskiner, signaler, artefakter og runtime-metadata
  • WordPress-adapter = plugin-opstart, hook-broer, WP-Cron-erstatning og WP-CLI-registrering

Det bevarer én orkestreringsmotor, mens hændelses- og anmodningsintegration, der er specifik for WordPress, forbliver dér, hvor den hører til.