Short map of published guides. Start with the Golden path for a linear first-hour setup, or JTBD and user flows if you want the mental model first.
For the current support/readiness contract, defended runtime posture, and maintainer proof-command split, use Support and compatibility.
Crash Course
Scrypath is easiest to think about as four layers:
- declaration:
use Scrypathmarks a schema with search metadata, but stays metadata-only - sync orchestration:
Scrypath.sync_record/3,Scrypath.backfill/2, andScrypath.reindex/2keep writes and recovery explicit - search runtime:
Scrypath.search/3,Scrypath.search_many/2, andScrypath.search_within_facet/4stay on one common query path - operator recovery:
Scrypath.sync_status/2,Scrypath.failed_sync_work/2,Scrypath.retry_sync_work/2, andScrypath.reconcile_sync/2keep drift visible
The intended app boundary is a Phoenix context that owns the search flow, with controllers and LiveView as thin callers.
| Guide | Purpose |
|---|---|
| JTBD and user flows | Canonical mental model: what jobs Scrypath serves, the main user flows, and what "success" honestly means in each one. |
| Common mistakes | Evidence-led pitfalls (symptom → wrong model → fix) with links back to canonical guides. |
| Getting started | Mental model: what you configure, where sync and search live in the app. |
| Golden path | Checklist from mix.exs through first Scrypath.search/3 with inline sync. |
| Support and compatibility | Single current support/readiness authority: runtime posture, defended Phoenix + Meilisearch path, proof commands, and clone-vs-Hex boundary. |
| Outside-Adopter Intake | Single canonical outside-adopter intake authority for gathering evidence on failed runs or outside integrations. |
| Request-edge search | Canonical v1.21 request-edge contract: browser params, Scrypath.QueryParams, optional Scrypath.Phoenix, and context-owned Scrypath.search/3. |
| Composing real-app search | Canonical v1.22 composition and metadata guide: defaults, fixed, host-owned rendering, and compose_many/2 lowering. |
| Related data and reindexing | Canonical guidance for associated-data fan-out, when direct sync is enough, and when to escalate to backfill or reindex. |
| Meilisearch operations | Where Meilisearch runs, provisioning sketches, recovery paths, and footguns—through a Scrypath lens. |
| Phoenix walkthrough | End-to-end Phoenix adoption: schema → context → controller → LiveView. |
| Phoenix contexts | Context-owned search and sync boundaries. |
| Phoenix controllers and JSON | JSON APIs and thin controller callers. |
| Phoenix LiveView | LiveView calling Scrypath.search/3 and related patterns. |
| Faceted search with Phoenix LiveView | Facets, filters, and catalog-style UIs. |
| Multi-index search | Federated / multi-index queries. |
| Sync modes and visibility | Inline, Oban, and manual sync semantics and what “done” means. |
| Operator Mix tasks | CLI entrypoints over Scrypath.* operator APIs. |
| Drift recovery | Operator path when DB and search disagree or work is stuck. |
| Relevance tuning | Meilisearch settings, verification, and tuning from schema declarations. |
| Per-query tuning pipeline | Request-time Meilisearch search parameters vs index-time settings — canonical merge and mapping spec. |
The runnable Phoenix example (Postgres + Meilisearch + Oban) lives under examples/phoenix_meilisearch/.