# Fristående användning

Queuety paketeras som ett plugin för WordPress, men det mesta av körningsmiljön behöver egentligen inte någon aktiv WordPress-begäran.

Kön, arbetsflödesmotorn, tillståndsmaskinerna, signalerna, artefakterna, batchhanteringen, schemaläggningen, loggningen, mätvärdena och resurshanteringen använder alla samma tabeller i MySQL. Om en annan PHP-process kan öppna samma databas kan den använda kärnan direkt.

Det är gränsen för fristående användning i Queuety. Den databasbaserade orkestreringsmotorn kan användas utanför WordPress. Bryggorna WordPress hör fortfarande till WordPress.

## Vad som fungerar utanför WordPress

Med en direkt `Connection` kan en fristående process initiera Queuety och använda samma fasadmetoder som pluginet använder för kärnans körningsmiljö:

- skicka jobb
- köra arbetare och arbetarpooler
- skapa och skicka iväg arbetsflöden
- skicka signaler, godkännanden och indata till arbetsflöden
- skapa och skicka iväg tillståndsmaskiner
- granska status för arbetsflöden och tillståndsmaskiner
- lagra och läsa artefakter
- hantera batchar, kedjor och återkommande scheman
- söka i loggar, mätvärden, köer och körningsstatus

Det innebär att en extern produkt kan kommunicera med samma orkestreringstillstånd utan att först starta WordPress, så länge den använder samma databas och tabellnamn.

Arbetarpooler är för närvarande det enda undantaget: `Queuety::run_worker_pool()` och `Queuety::run_auto_scaling_worker_pool()` läser konstanterna i WordPress `DB_HOST`, `DB_NAME`, `DB_USER` och `DB_PASSWORD` i stället för den initierade anslutningen. Därför måste en fristående process definiera dessa konstanter innan den startar en pool ([#5](https://github.com/inline0/queuety/issues/5)).

## Vad som hör hemma i WordPress

Brygglagret som är specifikt för WordPress är fortfarande beroende av att WordPress har lästs in.

Det omfattar:

- pluginstart och aktiveringsbeteende i `queuety.php`
- `Queuety::on_action()`, som kräver `add_action()`
- `Queuety::replace_wp_cron()` och `Queuety::restore_wp_cron()`, som är beroende av filtren i WordPress cron och `do_action()`
- den riktiga kommandoregistreringen för `wp queuety ...`, som är beroende av att WP-CLI läser in WordPress

De delarna är adaptrar runt kärnans körningsmiljö. De utgör inte själva körningsmiljön.

## Initiering

Den fristående vägen är avsiktligt enkel. Öppna en databasbaserad `Connection`, initiera fasaden och kontrollera att schemat finns.

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

Därefter är de vanliga metoderna för körningsmiljön API tillgängliga:

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

## Tabellnamn

Fristående användning kräver inte specifikt WordPress-tabellnamn. Det enda som behövs är en stabil strategi för prefix.

Om du ansluter Queuety till en WordPress-databas använder du samma prefix som pluginet använder där. Om du använder Queuety i en separat databas kan anslutningens prefix vara vad ditt värdprogram förväntar sig. Tabellprefixet som är specifikt för Queuety styrs fortfarande av `QUEUETY_TABLE_PREFIX` och åsidosättningarna per tabell.

Inbäddade körningsmiljöer som delar en databas kan ange den del som är specifik för Queuety per anslutning:

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

Då lämnas databasens prefix för WordPress orört och tabeller som `queuety_jobs` kopplas till `wp_themequeue_jobs`.

## Tankemodell

Ett enkelt sätt att tänka på uppdelningen är:

- kärnan i Queuety = kö, arbetare, arbetsflöden, tillståndsmaskiner, signaler, artefakter och körningsmetadata
- adaptern för WordPress = pluginstart, bryggor för hooks, ersättning av WP-Cron och registrering av WP-CLI

På så sätt behåller du en orkestreringsmotor samtidigt som händelse- och förfrågningsintegrationen som är specifik för WordPress finns kvar där den hör hemma.