Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Example Apps & Framework Integrations

Tasker Contrib provides two things for each supported language:

  1. CLI plugin templates — code generators for tasker-ctl that scaffold handlers, task definitions, and infrastructure configuration
  2. Example applications — fully working apps that demonstrate real-world workflow patterns against published Tasker packages

The Integration Pattern

All four framework integrations follow the same pattern:

  1. Bootstraptasker-ctl init creates project structure with infrastructure config
  2. Createtasker-ctl template generate scaffolds handlers and task templates
  3. Process — Your handlers receive StepContext, execute business logic, return StepHandlerResult
  4. Query — Use the Tasker client SDK to submit tasks and check status

The framework integration layer is intentionally thin: it translates your framework’s idioms (Rails generators, FastAPI dependency injection, Bun middleware) into Tasker concepts without inventing new abstractions.

Available Integrations

FrameworkLanguageSDK PackageCLI Plugin
RailsRubytasker-core-rbtasker-contrib-rails
FastAPIPythontasker-pytasker-contrib-python
Hono/BunTypeScript@tasker-systems/taskertasker-contrib-typescript
AxumRusttasker-workertasker-contrib-rust

Each plugin provides templates for all handler types: step, API, decision, and batchable (Rust provides step handler only).

The Apps

AppFrameworkSDK PackageSource
rails-appRails 7tasker-core-rbGitHub
fastapi-appFastAPItasker-pyGitHub
bun-appHono/Bun@tasker-systems/taskerGitHub
axum-appAxumtasker-workerGitHub

Workflow Patterns

All four apps implement the same five workflow patterns, progressing from simple to complex:

PatternWorkflowHandler Types UsedStory
Linear pipelineE-commerce Order ProcessingStepPost 01
Parallel DAGData Pipeline AnalyticsStepPost 02
Diamond convergenceMicroservices User RegistrationStepPost 03
Namespace isolationCustomer Success + Payments RefundStepPost 04
Cross-team coordinationPayments ComplianceStepPost 04

Each workflow demonstrates a specific DAG pattern. The Engineering Stories series teaches these patterns through progressive narrative — start with Post 01 and work forward.

Shared Infrastructure

All example apps share a single docker-compose.yml that provides:

  • PostgreSQL with PGMQ extensions — state persistence and default message queue
  • Tasker orchestration engine — published GHCR image, handles DAG execution
  • RabbitMQ — optional message broker for event publishing
  • Dragonfly — Redis-compatible cache
cd examples
docker compose up -d

# Wait for orchestration to be healthy
curl -sf http://localhost:8080/health

Each app gets its own database (example_rails, example_fastapi, example_bun, example_axum) created by the shared init-db.sql script.

Running an Example

Python (FastAPI)

cd examples/fastapi-app
uv sync
uv run uvicorn app.main:app --port 8083

Ruby (Rails)

cd examples/rails-app
bundle install
bin/rails server -p 8082

TypeScript (Bun/Hono)

cd examples/bun-app
bun install
bun run dev

Rust (Axum)

cd examples/axum-app
cargo run

What to Study

Each app demonstrates the same concepts in its framework’s idioms. Comparing across languages is the fastest way to understand Tasker’s cross-language handler contract:

  • Handler registration — How each framework discovers and registers step handlers
  • Context accessget_input(), get_dependency_result(), and step configuration
  • Error handlingPermanentError vs RetryableError patterns
  • Task templates — Identical YAML DAG definitions across all four apps
  • Testing — Each app has integration tests that submit tasks and verify results

Getting Started

Source Repository

All example apps live in the tasker-systems/tasker-contrib repository under examples/.