Pular para o conteúdo

Uso independente

Ver como Markdown Editar no GitHub Documentação em 2cc7b2b

Queuety é distribuído como um plugin WordPress, mas a maior parte do runtime não precisa de uma solicitação WordPress ativa.

A fila, o mecanismo de workflow, as máquinas de estado, os sinais, os artefatos, o processamento em lote, o agendamento, o registro em log, as métricas e o gerenciamento de recursos funcionam nas mesmas tabelas de MySQL. Se outro processo PHP puder abrir o mesmo banco de dados, poderá usar esse núcleo diretamente.

Esse é o limite de uso independente em Queuety. O mecanismo de orquestração com banco de dados pode ser usado fora do WordPress. As pontes WordPress ainda pertencem ao WordPress.

O que funciona fora do WordPress

Com uma conexão Connection direta, um processo independente pode inicializar Queuety e usar os mesmos métodos de fachada que o plugin usa para o runtime central:

  • Despachar jobs
  • Executar workers e pools de workers
  • Criar e despachar workflows
  • Enviar sinais, aprovações e entradas de workflow
  • Criar e despachar máquinas de estado
  • Inspecionar o status de workflows e máquinas
  • Armazenar e ler artefatos
  • Executar processamento em lote, encadeamento e agendamentos recorrentes
  • Consultar logs, métricas, filas e status do runtime

Isso significa que um produto externo pode acessar o mesmo estado de orquestração sem inicializar WordPress primeiro, desde que use o mesmo banco de dados e os mesmos nomes de tabela.

Os pools de workers são a única exceção no momento: Queuety::run_worker_pool() e Queuety::run_auto_scaling_worker_pool() leem as constantes WordPress DB_HOST, DB_NAME, DB_USER e DB_PASSWORD, em vez da conexão inicializada; portanto, um processo independente precisa definir essas constantes antes de iniciar um pool (#5).

O que permanece dentro do WordPress

A camada de integração específica do WordPress ainda depende de WordPress estar carregado.

Isso inclui:

  • A inicialização do plugin e o comportamento de ativação no queuety.php
  • Queuety::on_action(), que requer add_action()
  • Queuety::replace_wp_cron() e Queuety::restore_wp_cron(), que dependem dos filtros WordPress cron e de do_action()
  • O caminho real de registro de comandos wp queuety ..., que depende de WP-CLI carregar WordPress

Essas partes são adaptadores em torno do runtime central. Elas não são o próprio runtime.

Inicialização

O caminho independente é intencionalmente simples. Abra um Connection com banco de dados, inicialize a fachada e garanta que o esquema exista.

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

Depois disso, a API normal do runtime estará disponível:

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

Nomenclatura das tabelas

O uso independente não exige especificamente os nomes de tabela de WordPress. Basta usar uma estratégia de prefixo estável.

Se você apontar Queuety para um banco de dados WordPress, use o mesmo prefixo que o plugin utiliza nele. Se usar Queuety em um banco de dados separado, o prefixo da conexão pode ser o que o aplicativo host esperar. A parte específica das tabelas de Queuety continua sendo controlada por QUEUETY_TABLE_PREFIX e pelas substituições por tabela.

Runtimes incorporados que compartilham um banco de dados podem definir essa parte específica de Queuety por conexão:

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

Isso mantém intacto o prefixo do banco de dados de WordPress e resolve tabelas como queuety_jobs para wp_themequeue_jobs.

Modelo mental

Uma forma clara de entender essa divisão é:

  • Núcleo de Queuety = fila, workers, workflows, máquinas de estado, sinais, artefatos e metadados do runtime
  • Adaptador de WordPress = inicialização do plugin, pontes de hooks, substituição de WP-Cron e registro de WP-CLI

Isso mantém um único mecanismo de orquestração, deixando a integração de eventos e solicitações específica do WordPress onde ela deve ficar.