# 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](https://github.com/inline0/queuety/issues/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.