Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Jason-AML/MonzaSport-Nextjs/llms.txt

Use this file to discover all available pages before exploring further.

Monza Motors uses four Supabase tables to power the entire platform. The vehicle catalog (vehiculos) holds every listing and references manufacturer plant records (fabricas) as well as supplemental media stored in stored. Chat history is persisted in messages, scoped to each authenticated user via a foreign key to Supabase’s built-in auth.users table.

​
Tables

​
vehiculos — Vehicle Catalog

The primary table. Every vehicle listing in the /collection route is sourced from here.
FieldTypeDescription
iduuidPrimary key
nombre_vehiculotextVehicle display name (e.g. “Apex GT-R”)
modelotextModel name / trim level
aniointegerModel year — used by getCollectionByYear() to filter listings
preciointegerPrice in USD
motortextEngine type or displacement (e.g. “4.0L Twin-Turbo V8”)
poder_hpintegerHorsepower output
aceleracion_0_100numeric0–100 km/h time in seconds
velocidad_maximaintegerTop speed in km/h
torque_nmintegerTorque in Newton-metres
peso_kgintegerCurb weight in kilograms
url_imgtextPrimary image URL (served from Supabase Storage or remote CDN)
descriptiontextLong-form vehicle description displayed on the detail page

​
fabricas — Manufacturer Plants

Holds manufacturer and facility metadata. Each vehicle is linked to one plant record.
FieldTypeDescription
iduuidPrimary key
fabricantetextManufacturer name (e.g. “Apex Motors”)
nombre_plantatextProduction facility / plant name
ciudadtextCity where the plant is located
paistextCountry of the facility

​
stored — Vehicle Media & Metadata

stored rows are fetched as a joined sub-select on vehiculos via stored(*). They hold supplemental media assets or structured metadata records associated with a vehicle.
FieldTypeDescription
(joined via stored(*) select)—Additional media files or metadata associated with the parent vehicle record
The full column definition for stored is managed in your Supabase project dashboard. Because it is always fetched as stored(*) in a join, any columns you add automatically become available on the vehicle detail response without changing the query.

​
messages — AI Chat History

Stores every message exchanged in the AI chat interface, keyed by authenticated user.
FieldTypeDescription
iduuidPrimary key
user_iduuidForeign key → auth.users.id
roletextEither 'user' or 'assistant'
contenttextFull message text
created_attimestamptzUTC timestamp set automatically on insert

​
Relationships

auth.users
    │
    └── messages.user_id  (one user → many messages)

vehiculos
    ├── fabricas.id       (one vehicle → one manufacturing plant)
    └── stored.*          (one vehicle → many media/metadata records)
  • vehiculos → fabricas: A vehicle belongs to exactly one manufacturer plant. The join is expressed as vehiculos.select('*, fabricas(*), stored(*)') in getCollectionById.
  • vehiculos → stored: The stored table is fetched as a nested join on the vehicle detail query. Multiple stored records can be associated with a single vehicle.
  • messages → auth.users: messages.user_id references the Supabase-managed auth.users table, ensuring every message is tied to a verified account.

​
Row-Level Security

Row-Level Security (RLS) must be enabled on all tables. The following policies are recommended for a production deployment.
messages — users should only access their own chat history: 
-- Allow authenticated users to read their own messages
CREATE POLICY "Users can read own messages"
ON messages FOR SELECT
USING (auth.uid() = user_id);

-- Allow authenticated users to insert their own messages
CREATE POLICY "Users can insert own messages"
ON messages FOR INSERT
WITH CHECK (auth.uid() = user_id);
vehiculos and fabricas — public catalog data, readable by everyone: 
-- Public read access for the vehicle catalog
CREATE POLICY "Public can read vehiculos"
ON vehiculos FOR SELECT
USING (true);

CREATE POLICY "Public can read fabricas"
ON fabricas FOR SELECT
USING (true);
Without RLS policies in place, any authenticated user could read or write any row in any table. Always enable RLS and define explicit policies before deploying to production.

​
Realtime

Supabase Realtime is enabled on the messages table so that AI assistant replies appear in the chat interface instantly — without polling. The useChat hook in src/hooks/useChat.js subscribes to INSERT events on messages, filtered by the current user’s id: 
const channel = supabase
  .channel('chat-' + user.id)
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'messages',
      filter: `user_id=eq.${user.id}`
    },
    (payload) => {
      setMessages(prev => [...prev, payload.new])
    }
  )
  .subscribe()
When the POST /api/chat route handler writes the assistant’s reply to messages, the Realtime subscription fires immediately and appends the new message to the local state — delivering a live, push-based chat experience.
The channel name is scoped to 'chat-' + user.id, so each user gets an isolated Realtime channel. This prevents one user’s messages from leaking into another user’s subscription.

Build docs developers (and LLMs) love

Get started for freeTalk to us