Lewati ke konten

Penggunaan Mandiri

Queuety dikemas sebagai plugin WordPress, tetapi sebagian besar runtime sebenarnya tidak memerlukan permintaan WordPress yang aktif.

Antrean, mesin alur kerja, mesin status, sinyal, artefak, pemrosesan batch, penjadwalan, pencatatan log, metrik, dan pengelolaan sumber daya semuanya berjalan menggunakan tabel MySQL yang sama. Jika proses PHP lain dapat membuka database yang sama, proses tersebut dapat langsung menggunakan inti itu.

Itulah batas penggunaan mandiri di Queuety. Mesin orkestrasi berbasis database dapat digunakan di luar WordPress. Bridge WordPress tetap menjadi bagian dari WordPress.

Fitur yang berfungsi di luar WordPress

Dengan Connection langsung, proses mandiri dapat menginisialisasi Queuety dan menggunakan metode facade yang sama dengan yang digunakan plugin untuk runtime inti:

  • mengirim pekerjaan
  • menjalankan worker dan pool worker
  • membuat dan mengirim alur kerja
  • mengirim sinyal, persetujuan, dan input alur kerja
  • membuat dan mengirim mesin status
  • memeriksa status alur kerja dan mesin
  • menyimpan dan membaca artefak
  • menjalankan pemrosesan batch, chaining, dan jadwal berulang
  • membuat kueri log, metrik, antrean, dan status runtime

Dengan demikian, produk eksternal dapat mengakses status orkestrasi yang sama tanpa lebih dulu menjalankan WordPress, asalkan menggunakan database dan nama tabel yang sama.

Untuk saat ini, pool worker adalah satu pengecualian: Queuety::run_worker_pool() dan Queuety::run_auto_scaling_worker_pool() membaca konstanta WordPress DB_HOST, DB_NAME, DB_USER, dan DB_PASSWORD alih-alih koneksi yang diinisialisasi. Karena itu, proses mandiri harus menetapkan konstanta tersebut sebelum memulai pool (#5).

Bagian yang tetap berada di dalam WordPress

Lapisan bridge khusus WordPress tetap bergantung pada WordPress yang dimuat.

Ini mencakup:

  • bootstrap plugin dan perilaku aktivasi di queuety.php
  • Queuety::on_action(), yang memerlukan add_action()
  • Queuety::replace_wp_cron() dan Queuety::restore_wp_cron(), yang bergantung pada filter WordPress cron dan do_action()
  • jalur pendaftaran perintah wp queuety ... yang sebenarnya, yang bergantung pada WP-CLI memuat WordPress

Bagian-bagian tersebut adalah adaptor untuk runtime inti. Bagian itu bukan runtime itu sendiri.

Inisialisasi

Jalur mandiri sengaja dibuat ringkas. Buka Connection berbasis DB, inisialisasi facade, dan pastikan skema tersedia.

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

Setelah itu, API runtime standar tersedia:

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

Penamaan Tabel

Penggunaan mandiri tidak memerlukan nama tabel khusus WordPress. Yang diperlukan hanyalah strategi prefiks yang konsisten.

Jika Anda menghubungkan Queuety ke database WordPress, gunakan prefiks yang sama dengan yang digunakan plugin di sana. Jika Anda menggunakan Queuety di database terpisah, prefiks koneksinya dapat mengikuti kebutuhan aplikasi host Anda. Bagian tabel khusus Queuety tetap dikendalikan oleh QUEUETY_TABLE_PREFIX dan penggantian per tabel.

Runtime tertanam yang berbagi satu database dapat menetapkan bagian khusus Queuety tersebut untuk setiap koneksi:

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

Dengan begitu, awalan basis data WordPress tetap utuh dan tabel seperti queuety_jobs dipetakan ke wp_themequeue_jobs.

Model Mental

Cara paling tepat untuk memahami pemisahan ini adalah:

  • inti Queuety = antrean, worker, alur kerja, mesin status, sinyal, artefak, dan metadata runtime
  • adapter WordPress = bootstrap plugin, jembatan hook, pengganti WP-Cron, dan pendaftaran WP-CLI

Dengan begitu, satu mesin orkestrasi tetap digunakan, sementara integrasi event dan permintaan khusus WordPress tetap berada di tempat yang semestinya.