Build the product UI first. Let the data API catch up automatically.

Prototype backends collapse when filters become real.

A product grid starts simple, then users expect narrowing filters: category, brand, price range, availability, tags, rating, location, owner, variant, and more. With a conventional app backend, each new facet usually means schema work, seed scripts, API changes, and UI-specific endpoints before the prototype can prove the product idea.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

{
  "prototypeId": "shop-demo-01",
  "name": "Home office catalogue",
  "SCREEN": [{
    "slug": "catalog",
    "layout": "grid",
    "PRODUCT_CARD": [{
      "productId": "desk-lamp-01",
      "title": "Adjustable brass desk lamp",
      "category": "lighting",
      "brand": "Northstar Home",
      "priceUsd": 128,
      "rating": 4.8,
      "inStock": true,
      "tags": ["desk", "warm-light", "brass"],
      "VARIANT": [{ "color": "brass", "finish": "matte", "stock": 18 }],
      "MEDIA_ASSET": [{ "kind": "image", "url": "/demo/lamp.jpg" }]
    }]
  }]
}

Working example

Push catalogue JSON. Render filters from live metadata.

A prototype writes product-card JSON into RushDB. The UI reads available labels, discovers filterable properties and values, then narrows the product grid with a SearchQuery instead of waiting for custom backend routes.

PRODUCT_CARD desk-lamp-01
  title: "Adjustable brass desk lamp"
  category: lighting
  brand: Northstar Home
  priceUsd: 128
  rating: 4.8
  inStock: true
  VARIANT brass / matte / stock 18

{
  "labels": ["PRODUCT_CARD"],
  "where": {
    "category": "lighting",
    "priceUsd": { "$lte": 200 },
    "inStock": true
  },
  "orderBy": { "priceUsd": "asc" },
  "limit": 24
}

{
  "records": [{ "productId": "desk-lamp-01", "title": "Adjustable brass desk lamp" }],
  "facets": {
    "labels": ["PRODUCT_CARD", "VARIANT"],
    "properties": ["category", "brand", "priceUsd", "rating", "inStock"],
    "categoryValues": ["lighting", "office", "furniture"]
  }
}

TypeScript SDK

One prototype data path: write JSON, inspect metadata, query records.

Use the SDK for writes and record queries. Use the Labels and Properties APIs for dynamic facets: record types, filterable properties, distinct values, numeric ranges, and result lists.

Implementation blueprint

Build the faceted prototype path.

Use this sequence to replace early backend scaffolding with RushDB-backed data discovery and record queries while the product shape is still changing.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.