Blueprint: rapid prototyping

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

When you are vibe-coding a marketplace, catalogue, directory, or internal tool, the slow part is often not the UI. It is creating tables, API routes, and filter-metadata endpoints before the product is valuable. RushDB lets you push PRODUCT_CARD JSON with nested VARIANT records the way your UI already renders it, then use labels, properties, and property values to power category, price, and stock facets like a serious ecommerce platform.

Rapid Prototyping With Faceted Search is a RushDB blueprint for vibe-coded MVPs that pushes UI-shaped PRODUCT_CARD JSON directly into RushDB, then builds filter panels from live labels, properties, and values instead of hand-built backend endpoints.

Prototype backends collapse when filters become real.

A PRODUCT_CARD grid starts simple, then users expect narrowing filters: category, brand, priceUsd range, inStock availability, rating, and VARIANT options like color or finish. With a conventional app backend, each new facet usually means schema migrations, seed scripts, and new API routes before the prototype can prove whether the product idea even works.

Before

  • Model tables and joins before the UI proves the product
  • Build separate endpoints for records, filter options, counts, and value ranges
  • Rework the backend every time the prototype adds a new property
  • Flatten rich UI cards into rigid rows too early

With RushDB

  • Push UI-shaped JSON as Records and nested Records
  • Fetch labels to know which record types exist
  • Fetch properties and property values to build dynamic facets
  • Query records with selected filters, sorting, and pagination through RushDB

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A PRODUCT_CARD payload nests VARIANT entries such as color, finish, and stock straight from the UI. RushDB infers types for priceUsd, rating, and inStock as the JSON lands, turns each VARIANT into a linked child record, and immediately exposes category and brand as queryable properties so facet panels can read live values instead of a hardcoded filter list.

01

Normalize as cards are pushed

RushDB infers types for priceUsd, rating, and inStock the moment each PRODUCT_CARD JSON payload is written.

02

Auto-link variants

Nested VARIANT entries like color, finish, and stock become connected child records under their parent PRODUCT_CARD automatically.

03

Enrich facet options

Suggested-relationship analysis surfaces links between PRODUCT_CARD, BRAND, and CATEGORY records so facet panels stay current as new tags appear.

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.

Review suggested relationship patterns

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.

Schema sketch
Prototype catalogue payload

Prototype data can follow the UI shape first. RushDB turns the nested cards, variants, categories, and media into queryable Records.

{
  "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.

Input
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
Query
{
  "labels": ["PRODUCT_CARD"],
  "where": {
    "category": "lighting",
    "priceUsd": { "$lte": 200 },
    "inStock": true
  },
  "orderBy": { "priceUsd": "asc" },
  "limit": 24
}
Result
{
  "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.

import requests
from rushdb import RushDB

API_KEY = 'RUSHDB_API_KEY'
API_URL = 'https://api.rushdb.com/api/v1'
headers = {'Authorization': f'Bearer {API_KEY}', 'Content-Type': 'application/json'}

db = RushDB(API_KEY)

db.records.import_json({
    'label': 'PRODUCT_CARD',
    'data': {
        '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}],
    },
})

labels = requests.post(f'{API_URL}/labels/search', headers=headers, json={}).json()
properties = requests.post(f'{API_URL}/properties/search', headers=headers, json={}).json()
category_prop = next(prop for prop in properties['data'] if prop['name'] == 'category')
category_values = requests.post(f"{API_URL}/properties/{category_prop['id']}/values", headers=headers, json={}).json()

records = db.records.find({
    'labels': ['PRODUCT_CARD'],
    'where': {'category': 'lighting', 'priceUsd': {'$lte': 200}, 'inStock': True},
    'orderBy': {'priceUsd': 'asc'},
    'limit': 24,
})

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.

  1. 01Push PRODUCT_CARD JSON in the same shape the UI renders
  2. 02Fetch labels to list available record types and counts
  3. 03Fetch properties to build filter controls and understand field types
  4. 04Fetch property values or ranges to narrow available options
  5. 05Query records with selected filters, order, pagination, and optional graph traversal

Build path

  • Use Labels and Properties docs for faceted metadata.
  • Use PRODUCT_CARD for rendered cards and nested VARIANT, MEDIA_ASSET, CATEGORY, or BRAND records when useful.
  • Let new JSON fields appear as properties instead of blocking the prototype on migrations.
  • Move behind a thin server proxy before production if browser access, rate limits, tenancy, or permissions matter.

How it works

Build the smallest useful workflow first.

01

Push the UI payload

Write the product card, directory item, marketplace offer, or internal-tool row as JSON first. Keep nested UI details nested.

02

Generate facets from metadata

Read labels, properties, and property values to create filter panels that narrow options as data changes.

03

Query records for the screen

Use one SearchQuery for the result grid: filters, sorting, pagination, and connected records when the UI needs drill-down context.

Know where it fits.

Useful for serious prototypes

The point is not throwaway mock data. It is getting to a valuable product loop before the backend schema is fully settled.

Facets come from stored data

A top-tier filter experience needs available values and ranges to narrow as users browse. RushDB exposes the metadata needed to build that from the data you already wrote.

Questions developers ask.