# Samostatné použití

Queuety je distribuován jako plugin WordPress, ale většina běhového prostředí ve skutečnosti nepotřebuje aktivní požadavek WordPress.

Fronta, workflow engine, stavové automaty, signály, artefakty, dávkování, plánování, protokolování, metriky a správa prostředků pracují se stejnými tabulkami MySQL. Pokud jiný proces PHP dokáže otevřít stejnou databázi, může toto jádro používat přímo.

To je hranice samostatného použití v Queuety. Orchestrace řízená databází je použitelná i mimo WordPress. Mosty WordPress stále patří do WordPress.

## Co funguje mimo WordPress

Při přímém připojení `Connection` může samostatný proces inicializovat Queuety a používat stejné metody fasády jako plugin pro běhové jádro:

- odesílat úlohy
- spouštět workery a jejich pooly
- vytvářet a odesílat workflow
- odesílat signály, schválení a vstupní data workflow
- vytvářet a spouštět stavové automaty
- kontrolovat stav workflow a automatů
- ukládat a číst artefakty
- řídit dávkování, řetězení a opakované plánování
- dotazovat se na protokoly, metriky, fronty a stav běhového prostředí

To znamená, že externí produkt může pracovat se stejným stavem orchestrace, aniž by nejprve spustil WordPress, pokud používá stejnou databázi a názvy tabulek.

Pooly workerů jsou nyní jedinou výjimkou: `Queuety::run_worker_pool()` a `Queuety::run_auto_scaling_worker_pool()` čtou konstanty WordPress `DB_HOST`, `DB_NAME`, `DB_USER` a `DB_PASSWORD` namísto inicializovaného připojení, takže samostatný proces musí tyto konstanty definovat před spuštěním poolu ([#5](https://github.com/inline0/queuety/issues/5)).

## Co zůstává uvnitř WordPress

Vrstva mostů specifická pro WordPress je stále závislá na načtení WordPress.

Patří sem:

- inicializace pluginu a jeho aktivace v `queuety.php`
- `Queuety::on_action()`, které vyžaduje `add_action()`
- `Queuety::replace_wp_cron()` a `Queuety::restore_wp_cron()`, které závisí na filtrech WordPress cron a `do_action()`
- skutečná cesta registrace příkazů `wp queuety ...`, která závisí na načtení WordPress pomocí WP-CLI

Tyto části jsou adaptéry kolem běhového jádra. Samotné běhové prostředí netvoří.

## Inicializace

Samostatná cesta je záměrně jednoduchá. Otevřete databázové připojení `Connection`, inicializujte fasádu a zajistěte existenci schématu.

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

Poté je k dispozici běžné běhové API:

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

## Pojmenování tabulek

Samostatné použití nevyžaduje konkrétně názvy tabulek WordPress. Potřebuje pouze stabilní strategii předpon.

Pokud nasměrujete Queuety na databázi WordPress, použijte stejnou předponu, jakou tam používá plugin. Pokud použijete Queuety v samostatné databázi, může být předpona připojení libovolná podle požadavků hostitelské aplikace. Část názvu tabulky specifická pro Queuety se stále řídí pomocí `QUEUETY_TABLE_PREFIX` a individuálních přepsání pro jednotlivé tabulky.

Vložená běhová prostředí sdílející jednu databázi mohou tuto část specifickou pro Queuety nastavit pro každé připojení:

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

Tím zůstane předpona databáze WordPress nedotčená a tabulky jako `queuety_jobs` se převedou na `wp_themequeue_jobs`.

## Mentální model

Rozdělení lze nejlépe chápat takto:

- jádro Queuety = fronta, workeři, workflow, stavové automaty, signály, artefakty a metadata běhového prostředí
- adaptér WordPress = inicializace pluginu, mosty háčků, náhrada WP-Cron a registrace WP-CLI

Díky tomu zůstává jeden orchestrace engine a integrace událostí a požadavků specifická pro WordPress je tam, kam patří.