# Zelfstandig gebruik

Queuety is verpakt als een WordPress-plugin, maar voor het grootste deel van de runtime is geen actieve WordPress-aanvraag nodig.

De wachtrij, workflowengine, statusmachines, signalen, artefacten, batchverwerking,
planning, logboekregistratie, statistieken en het resourcebeheer werken allemaal met dezelfde
MySQL-tabellen. Als een ander PHP-proces dezelfde database kan openen, kan het die
kern rechtstreeks gebruiken.

Dat is de grens voor zelfstandig gebruik in Queuety. De databasegestuurde orkestratie-
engine kan buiten WordPress worden gebruikt. De WordPress-bruggen horen nog steeds bij
WordPress.

## Wat buiten WordPress werkt

Met een directe `Connection`-verbinding kan een zelfstandig proces Queuety initialiseren en
dezelfde facademethoden gebruiken als de plugin voor de runtimekern:

- taken versturen
- workers en workerpools uitvoeren
- workflows opbouwen en versturen
- signalen, goedkeuringen en workflowinvoer verzenden
- statusmachines opbouwen en uitvoeren
- de status van workflows en statusmachines bekijken
- artefacten opslaan en lezen
- batchverwerking, ketenvorming en terugkerende planningen uitvoeren
- logboeken, statistieken, wachtrijen en runtimestatus opvragen

Zo kan een extern product communiceren met dezelfde orkestratiestatus zonder
WordPress eerst te starten, zolang het dezelfde database- en tabelnamen gebruikt.

Workerpools vormen voorlopig de enige uitzondering: `Queuety::run_worker_pool()` en
`Queuety::run_auto_scaling_worker_pool()` lezen de constanten WordPress `DB_HOST`,
`DB_NAME`, `DB_USER` en `DB_PASSWORD` in plaats van de geïnitialiseerde verbinding. Een zelfstandig proces moet die constanten daarom instellen voordat het een pool start ([#5](https://github.com/inline0/queuety/issues/5)).

## Wat binnen WordPress blijft

De bruggelaag die specifiek is voor WordPress is nog steeds afhankelijk van het laden van WordPress.

Dat omvat:

- het bootstrap- en activeringsgedrag van de plugin in `queuety.php`
- `Queuety::on_action()`, waarvoor `add_action()` nodig is
- `Queuety::replace_wp_cron()` en `Queuety::restore_wp_cron()`, die afhankelijk zijn van de filters WordPress cron en `do_action()`
- het daadwerkelijke registratiepad van de opdracht `wp queuety ...`, dat afhankelijk is van het laden van WP-CLI WordPress

Dit zijn adapters rond de runtimekern. Ze vormen niet de runtime zelf.

## Initialisatie

Het zelfstandige pad is bewust klein gehouden. Open een DB-gestuurde `Connection`,
initialiseer de facade en zorg dat het schema bestaat.

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

Daarna is de normale runtime-API beschikbaar:

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

## Tabelnamen

Voor zelfstandig gebruik zijn WordPress-tabelnamen niet specifiek nodig. Er is alleen een
stabiele prefixstrategie nodig.

Als u Queuety naar een WordPress-database laat verwijzen, gebruik dan dezelfde prefix als de
plugin daar gebruikt. Als u Queuety in een aparte database gebruikt, kan de verbindingsprefix zijn wat uw hostapplicatie verwacht. Het Queuety-specifieke tabelgedeelte wordt nog steeds bepaald door `QUEUETY_TABLE_PREFIX` en de overschrijvingen per tabel.

Ingebedde runtimes die één database delen, kunnen dat Queuety-specifieke gedeelte
per verbinding instellen:

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

Zo blijft de databaseprefix van WordPress intact en worden tabellen zoals
`queuety_jobs` omgezet naar `wp_themequeue_jobs`.

## Mentaal model

De eenvoudigste manier om over deze verdeling na te denken is:

- Queuety-kern = wachtrij, workers, workflows, toestandsmachines, signalen, artefacten en runtimemetagegevens
- WordPress-adapter = plugin-bootstrap, hookbruggen, vervanging van WP-Cron en registratie van WP-CLI

Zo blijft er één orkestratie-engine, terwijl de WordPress-specifieke gebeurtenis- en
verzoekintegratie op de juiste plek blijft.