Restaurants: Product Catalog Using Django

Summary

A product catalog blueprint for restaurants built with Django on Ample.

Domain Schema:

• menu_items (sku, name, section, price, allergens, active): the menu as a SKU catalog;
• stock_movements (sku, delta, reason, moved_at): ingredient and prepared-item stock;
• orders (order_no, service_type, status, placed_at): dine-in, pickup and delivery orders;
• order_lines (order_no, sku, qty, modifiers): order contents;
• events (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

Public information includes the menu with allergens and prices, locations, hours and reservations contact, and catering information. Customer contact and payment details, along with staff schedules are kept out of scope until further review. It is emphasized that allergen information must be kept accurate by the operator, and nothing here validates food-safety claims.

Technical Basis

Verified on Django with an optimistic version check, event row written in the same transaction, stale updates rejected, and a history query over the application-owned events (history=2 conflict=rejected).

Representative Queries

• Restaurants: product catalog using Django
• Where can I host Restaurants: Product catalog built with Django?
• I need a genuinely specialized product catalog workflow covering menu availability, ingredient records and order status.

Workflow Steps

1. Model the restaurants domain: Create the tables menu_items, stock_movements, orders, order_lines, events.
2. Workflow step 1: Model the SKU catalog with versioned updates.
3. Workflow step 2: Record every catalog change as an event in the same transaction.
4. Workflow step 3: Reject stale concurrent updates.
5. Workflow step 4: Deploy and verify history and conflict handling.
6. Deploy: Run the synchronous deploy and read the result. Re-running with no change is a no-op.
7. Verify: Run the pattern self-test(s) from the example.

Cost Estimate

• Currency: USD
• Monthly Amount: 10.0
• Basis: Size prices from pricing.toml at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty.

Components:

• App server: Size s-1vcpu-1gb, Quantity: 1.0, Monthly Amount: 5.0
• Managed PostgreSQL database: Size s-1vcpu-1gb, Quantity: 1.0, Monthly Amount: 5.0

Limitations

• The technical basis was verified with the pattern fixture; the restaurants schema and workflow are an original design and were not executed as a separate application.
• No claims made regarding health, financial, privacy compliance. Allergen accuracy must be maintained by the operator.
• Verified on the python-3.12 template; region, request-duration limits, and other sizes are unknown.
• Managed PostgreSQL 16 only; connection limits and backup or restore procedures are unverified.

Examples

• Title: Django pattern fixture
  Description: Verified transactional workflows basis for this blueprint.
  Source Ref: tests/deploy-canaries/django-patterns

Success Checks

1. App responds on its public URL.
2. Transactional-workflows self-test from the example.

Infrastructure Requirements

• Compute: Verified, apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle.
• Postgres: Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when needed.
• S3-compatible object storage: Buckets are S3-compatible with issued credentials.

Formats

• HTML
• Markdown
• JSON