Add Dagster orchestration and reduce active brands in backend

This commit is contained in:
sriram
2026-08-20 16:39:54 +05:30
parent fbb1356e47
commit 7bf8dc6922
66 changed files with 2664 additions and 21 deletions

View File

@@ -52,6 +52,58 @@ uvicorn app.main:app --reload --port 8000
Then open http://localhost:8000/docs for interactive API docs, or run the
frontend (`../frontend/README.md`) to use the React UI.
## Active brands (development working set)
One setting decides which brands the application and every pipeline work on:
```
# backend/.env
ACTIVE_BRANDS=Amul,Cadbury,Hindustan Unilever
```
**Blank or unset means every brand is active** - that is the production default
and the way to turn the feature off.
Nothing is deleted when it is set. The other `brand_*` tables and their
embeddings stay in Postgres untouched; they simply stop being discovered.
Everything downstream inherits it, because the whole app funnels through two
functions in `app/services/vector_store.py`
(`list_available_brands` and `_list_brand_table_suffixes`):
```
ACTIVE_BRANDS
|
+-- /api/brands, /api/products, /api/search, /api/suggest
+-- RAG chat and the query_intent brand index
+-- MCP tools
+-- nutrition enrichment, store intelligence, analytics
+-- the boot auto-seed and the 300s brand reconcile
+-- every Dagster asset and partition
```
Going from 3 brands to 5, 10 or all of them is an edit to this one line - no
code changes. Catalogs for inactive brands live in
`data/seed_catalogs/archive/`, which the loader still reads, so re-activating a
brand does not require moving files back.
Names resolve through the brand aliases, so `ACTIVE_BRANDS=Tata` activates
`brand_hindustan_unilever` - the same table an ingest of Tata products targets.
## Orchestration (Dagster)
Ingestion, enrichment, embedding and ML training can be run as a Dagster asset
graph, with lineage, retries and run history. It is a **development tool** -
FastAPI still serves every request and nothing in a request path touches it.
```
pip install -r requirements-orchestration.txt
DAGSTER_HOME="$(pwd)/orchestration/.dagster_home" dagster dev -m orchestration.definitions -p 3030
```
See `orchestration/README.md`. Note that it pins itself to the **local**
database and refuses to write to a remote one, because `backend/.env` points at
production.
## Authentication
Reads are public; the 18 write/compute endpoints require a credential, enforced