A database course, with a real app on top.
The fourth-semester DBMS course asked for a database project. I wanted the schema to sit under something that felt like a real tool, so InvenSync became a full stack app. It has a dashboard that counts low-stock items, plus pages for inventory, suppliers, customers and orders, all backed by six related tables.
Stock, suppliers, customers, orders.
These screens show the real frontend running against a local stand-in for the API, filled with made-up hardware-shop data. No real shop or customer data is shown.
Six tables, joined by foreign keys.
The course was about the database, so most of the design went here. Items belong to suppliers. Stock lives in its own inventory table rather than on the item. Incoming supply is recorded as rows of its own, and each order points to the item, the supplier and the customer.
- id
- name
- sku
- category
- price
- supplier_id → supplier
- id
- name
- address
- gstno
- id
- name
- address
- phone_no
- gender
- dob
- item_id → items
- supplier_id → supplier
- quantity
- stockstatus
- item_id → items
- supplier_id → supplier
- quantity
- id
- item_id → items
- supplier_id → supplier
- customer_id → customers
- quantity
- order_date
- expected_date
- status
- total_price
When the dashboard asks for inventory, one query pulls each stock row with its item's name, SKU, category and price, and its supplier's name, using Supabase's nested selects over those foreign keys.
A thin layer the frontend can trust.
Every request goes through FastAPI, never straight from the browser to the database. Pydantic models validate what comes in and shape what goes out, so the React side always gets the same structure.
Three pieces.
TypeScript, Tailwind, shadcn/ui components and recharts. The UI shell started from a Lovable template; I wired every page to the API and reworked the pages around the real tables.
Grew from 62 lines in the first commit to about 480 by submission. Keys come from environment variables.
Hosted Postgres, reached through the Supabase Python client.
What I'd change.
The login screen accepts any email and password; it was a placeholder that never got real authentication. The dashboard and order pages each make several separate requests where one endpoint would do, and the API URL is hard-coded in each page. These are small fixes, but they're the ones I noticed first when I opened the project again.