Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/astrxnomo/shop-microservers/llms.txt

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

Shop Microservers uses Prisma ORM with three logical PostgreSQL 16 databases. Each service that needs persistence manages its own Prisma schema independently — there is no shared ORM instance or shared schema file. This keeps the data boundary between services explicit and enforced at the schema level. The three databases are auth_db (managed by the auth service), catalog_db (managed by the catalog service), and orders_db (managed by the orders service).

​
Databases at a Glance

DatabaseUsed ByTables
auth_dbauth serviceUser
catalog_dbcatalog serviceProduct
orders_dborders serviceOrder, OrderItem
Each service owns its own dedicated database. The auth service owns auth_db and manages the User table; the orders service owns orders_db and manages the Order and OrderItem tables. Neither service uses the other’s Prisma client.

​
Schema Reference

​
Auth — User

The auth service stores one record per registered user. Passwords are stored as bcrypt hashes; the plain-text password is never persisted. 
model User {
  id           String   @id @default(cuid())
  email        String   @unique
  passwordHash String
  createdAt    DateTime @default(now())
}

​
Catalog — Product

The catalog service stores the full product inventory. The stock field is decremented atomically by the orders service at checkout time via the catalog’s stock endpoint. 
model Product {
  id        String   @id @default(cuid())
  name      String
  price     Float
  imageUrl  String
  stock     Int      @default(0)
  category  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

​
Orders — Order, OrderItem, and OrderStatus

The orders service records each completed checkout as an Order with one or more OrderItem rows. Product details (name, price) are copied into OrderItem at the time of purchase so that the record remains accurate even if the catalog changes later. 
model Order {
  id        String      @id @default(cuid())
  userId    String
  items     OrderItem[]
  total     Float
  status    OrderStatus @default(PENDING)
  createdAt DateTime    @default(now())
  updatedAt DateTime    @updatedAt
}

model OrderItem {
  id        String @id @default(cuid())
  orderId   String
  order     Order  @relation(fields: [orderId], references: [id])
  productId String
  name      String
  price     Float
  quantity  Int
}

enum OrderStatus {
  PENDING
  CONFIRMED
  SHIPPED
  DELIVERED
  CANCELLED
}

​
Migration Commands

All three services with a database expose the same npm scripts for schema management. 
# Apply the schema to the database (used in local development)
npm run db:push      # runs: prisma db push

# Regenerate the Prisma client after schema changes
npm run db:generate  # runs: prisma generate

# Seed the catalog with 12 sample products (catalog service only)
npm run db:seed      # runs: tsx prisma/seed.ts
In the Docker Compose setup, each service’s CMD runs prisma db push on startup before launching the Express server. This applies the current schema state directly without creating a migration history file. For a production deployment, consider replacing prisma db push with prisma migrate deploy so that schema changes are tracked and applied incrementally.

​
Seeding the Catalog

The catalog seed script inserts 12 sample products across five categories (Electronics, Footwear, Accessories, Home & Kitchen, Sports). The seed is idempotent: it checks the current row count before inserting and skips entirely if any products already exist. 
cd services/catalog
npm run db:seed
Seed output when the table is empty: 
Poblando base de datos del catálogo...
12 productos creados.
Seed output when products already exist: 
Poblando base de datos del catálogo...
Omitiendo seed — ya existen 12 productos.
In the Docker Compose setup, the catalog service runs the seed automatically on first boot as part of its startup command, so you only need to run npm run db:seed manually when developing locally.

​
Prisma Client Output Location

Every service generates its Prisma client into ../generated/client — a directory that sits alongside prisma/ as a sibling, not inside it. This means each service has a completely isolated generated client. 
services/
  auth/
    prisma/
      schema.prisma
    generated/
      client/        ← auth's generated Prisma client
  catalog/
    prisma/
      schema.prisma
    generated/
      client/        ← catalog's generated Prisma client
  orders/
    prisma/
      schema.prisma
    generated/
      client/        ← orders' generated Prisma client
After making any change to a schema.prisma file, regenerate the client for that service: 
cd services/<service>
npm run db:generate
Never import a Prisma client from a different service. Each generated/client is tied to the schema of the service that owns it. Cross-importing clients would bypass the service boundary and create hidden coupling between services.

Build docs developers (and LLMs) love

Get started for freeTalk to us