# Użycie samodzielne

Queuety jest dostarczany jako wtyczka WordPress, ale większość środowiska uruchomieniowego nie potrzebuje aktywnego
żądania WordPress.

Kolejka, silnik przepływów pracy, maszyny stanów, sygnały, artefakty, grupowanie zadań, planowanie,
rejestrowanie, metryki i zarządzanie zasobami działają w oparciu o te same tabele
MySQL. Jeśli inny proces PHP może otworzyć tę samą bazę danych, może korzystać bezpośrednio z tego
rdzenia.

To właśnie granica użycia samodzielnego w Queuety. Silnik orkiestracji oparty na bazie danych działa poza WordPress. Mostki WordPress nadal należą do
WordPress.

## Co działa poza WordPress

Przy bezpośrednim połączeniu `Connection` samodzielny proces może zainicjować Queuety i używać tych samych metod fasady co wtyczka w podstawowym środowisku uruchomieniowym:

- uruchamiać zadania
- uruchamiać workery i pule workerów
- tworzyć i uruchamiać przepływy pracy
- wysyłać sygnały, zatwierdzenia i dane wejściowe do przepływu pracy
- tworzyć i uruchamiać maszyny stanów
- sprawdzać stan przepływów pracy i maszyn stanów
- zapisywać i odczytywać artefakty
- obsługiwać grupowanie zadań, łańcuchy i harmonogramy cykliczne
- odpytywać logi, metryki, kolejki i stan środowiska uruchomieniowego

Dzięki temu zewnętrzny produkt może komunikować się z tym samym stanem orkiestracji bez wcześniejszego uruchamiania WordPress, o ile korzysta z tej samej bazy danych i nazw tabel.

Obecnie jedynym wyjątkiem są pule workerów: `Queuety::run_worker_pool()` i
`Queuety::run_auto_scaling_worker_pool()` odczytują stałe WordPress `DB_HOST`,
`DB_NAME`, `DB_USER` i `DB_PASSWORD` zamiast zainicjowanego
połączenia, więc samodzielny proces musi zdefiniować te stałe przed
uruchomieniem puli ([#5](https://github.com/inline0/queuety/issues/5)).

## Co pozostaje w WordPress

Warstwa mostków specyficzna dla WordPress nadal wymaga załadowania WordPress.

Obejmuje to:

- uruchamianie wtyczki i zachowanie podczas aktywacji w `queuety.php`
- `Queuety::on_action()`, który wymaga `add_action()`
- `Queuety::replace_wp_cron()` i `Queuety::restore_wp_cron()`, które zależą od filtrów WordPress cron oraz `do_action()`
- właściwą ścieżkę rejestracji polecenia `wp queuety ...`, która wymaga załadowania WordPress przez WP-CLI

Te elementy są adapterami otaczającymi podstawowe środowisko uruchomieniowe. Nie stanowią samego środowiska.

## Inicjalizacja

Ścieżka samodzielna jest celowo prosta. Otwórz połączenie `Connection` oparte na bazie danych, zainicjuj fasadę i upewnij się, że schemat istnieje.

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

Następnie dostępny jest zwykły API środowiska uruchomieniowego:

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

## Nazewnictwo tabel

Do samodzielnego użycia nie są potrzebne konkretne nazwy tabel WordPress. Wystarczy stabilna strategia stosowania prefiksów.

Jeśli połączysz Queuety z bazą danych WordPress, użyj tego samego prefiksu co wtyczka. Jeśli używasz Queuety w osobnej bazie danych, prefiks połączenia może być zgodny z oczekiwaniami aplikacji hostującej. Część nazw tabel specyficzna dla Queuety jest nadal kontrolowana przez `QUEUETY_TABLE_PREFIX` i nadpisania dla poszczególnych tabel.

Środowiska uruchomieniowe osadzone we wspólnej bazie danych mogą ustawić tę część specyficzną dla Queuety osobno dla każdego połączenia:

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

Dzięki temu prefiks bazy danych WordPress pozostaje bez zmian, a tabele takie jak `queuety_jobs` są mapowane na `wp_themequeue_jobs`.

## Model myślowy

Najprościej rozumieć ten podział tak:

- rdzeń Queuety = kolejka, workery, przepływy pracy, maszyny stanów, sygnały, artefakty i metadane środowiska uruchomieniowego
- adapter WordPress = uruchamianie wtyczki, mostki hooków, zastępowanie WP-Cron i rejestracja WP-CLI

Dzięki temu jeden silnik orkiestracji obsługuje wszystkie zadania, a integracja zdarzeń i żądań specyficzna dla WordPress pozostaje na swoim miejscu.