The read-api plan calls out a MiniSearch fallback when better-sqlite3 (native bindings) is unavailable on a deploy target. The current implementation in apps/api/src/store/fts.ts only uses better-sqlite3; the fallback was not built, on the grounds that surfacing a clear error at boot is better than silently degrading to a less powerful search backend.
Decision needed:
- Confirm "surface the error" is the right policy long-term (cheaper to ensure native deps build on every target than to maintain two engines)
- Or implement a MiniSearch fallback behind the same
FtsEngine interface and gate it on a flag (e.g. an env var or a runtime probe)
Relevant files:
apps/api/src/store/fts.ts — current engineplans/read-api.md — risk notespecs/architecture.md — "Full-text search — in-memory SQLite FTS5 (or MiniSearch fallback)"
Originated from PR #22 (read-api).
The read-api plan calls out a MiniSearch fallback when
better-sqlite3(native bindings) is unavailable on a deploy target. The current implementation inapps/api/src/store/fts.tsonly usesbetter-sqlite3; the fallback was not built, on the grounds that surfacing a clear error at boot is better than silently degrading to a less powerful search backend.Decision needed:
FtsEngineinterface and gate it on a flag (e.g. an env var or a runtime probe)Relevant files:
apps/api/src/store/fts.ts— current engineplans/read-api.md— risk notespecs/architecture.md— "Full-text search — in-memory SQLite FTS5 (or MiniSearch fallback)"Originated from PR #22 (read-api).