Uso independiente
Queuety se distribuye como un plugin de WordPress, pero la mayor parte del entorno de ejecución no necesita una solicitud activa de WordPress.
La cola, el motor de flujos de trabajo, las máquinas de estado, las señales, los artefactos, el procesamiento por lotes, la programación, el registro, las métricas y la gestión de recursos funcionan con las mismas tablas de MySQL. Si otro proceso de PHP puede abrir la misma base de datos, puede usar directamente ese núcleo.
Ese es el límite de uso independiente en Queuety. El motor de orquestación respaldado por la base de datos puede usarse fuera de WordPress. Los puentes de WordPress siguen perteneciendo a WordPress.
Qué funciona fuera de WordPress
Con una Connection directa, un proceso independiente puede inicializar Queuety y usar los mismos métodos de fachada que el plugin usa para el entorno de ejecución principal:
- enviar trabajos
- ejecutar workers y grupos de workers
- crear y enviar flujos de trabajo
- enviar señales, aprobaciones y entradas de flujos de trabajo
- crear y enviar máquinas de estado
- inspeccionar el estado de los flujos de trabajo y las máquinas
- almacenar y leer artefactos
- ejecutar procesamiento por lotes, encadenamiento y programaciones recurrentes
- consultar registros, métricas, colas y el estado del entorno de ejecución
Esto permite que un producto externo acceda al mismo estado de orquestación sin iniciar WordPress primero, siempre que use la misma base de datos y los mismos nombres de tabla.
Hoy, los grupos de workers son la única excepción: Queuety::run_worker_pool() y Queuety::run_auto_scaling_worker_pool() leen las constantes WordPress DB_HOST, DB_NAME, DB_USER y DB_PASSWORD en lugar de la conexión inicializada, por lo que un proceso independiente debe definir esas constantes antes de iniciar un grupo (#5).
Qué sigue dentro de WordPress
La capa puente específica de WordPress sigue dependiendo de que WordPress esté cargado.
Esto incluye:
- el inicio del plugin y el comportamiento de activación en
queuety.php Queuety::on_action(), que requiereadd_action()Queuety::replace_wp_cron()yQueuety::restore_wp_cron(), que dependen de los filtros WordPress cron y dedo_action()- la ruta real de registro de comandos
wp queuety ..., que depende de que WP-CLI cargue WordPress
Esas piezas son adaptadores alrededor del entorno de ejecución principal. No son el entorno de ejecución en sí.
Inicialización
La ruta de uso independiente es deliberadamente sencilla. Abra una Connection respaldada por DB, inicialice la fachada y asegúrese de que el esquema exista.
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();
Después, estará disponible la API habitual del entorno de ejecución:
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();
Nombres de tabla
El uso independiente no requiere nombres de tabla de WordPress específicamente. Solo necesita una estrategia estable para los prefijos.
Si conecta Queuety a una base de datos de WordPress, use el mismo prefijo que utiliza el plugin allí. Si usa Queuety en una base de datos independiente, el prefijo de conexión puede ser el que espere la aplicación host. La parte del nombre de tabla específica de Queuety sigue controlada por QUEUETY_TABLE_PREFIX y las anulaciones por tabla.
Los entornos de ejecución integrados que comparten una base de datos pueden establecer esa parte específica de Queuety por conexión:
$conn = new Connection(
host: '127.0.0.1:3306',
dbname: 'wordpress',
user: 'root',
password: 'secret',
prefix: 'wp_',
table_prefix: 'themequeue_',
);
Así se conserva intacto el prefijo de base de datos de WordPress y se resuelven tablas como queuety_jobs en wp_themequeue_jobs.
Modelo mental
Una forma clara de entender la separación es:
- núcleo de Queuety = cola, workers, flujos de trabajo, máquinas de estado, señales, artefactos y metadatos del entorno de ejecución
- adaptador de WordPress = inicio del plugin, puentes de hooks, sustitución de WP-Cron y registro de WP-CLI
Así se mantiene un único motor de orquestación y se deja la integración de eventos y solicitudes específica de WordPress donde corresponde.