How tanshanbhogue/monopoly-bank-manager works
Purpose and runtime
Monopoly Bank Manager is a single-process web application for managing players, balances, and money transfers during one Monopoly game. It runs as a Python Flask server with intentionally ephemeral in-memory state; restarting the process loses the game.
Primary server entry point: app.py. Browser entry point: static/index.html.
Application boundary
app.py owns both the REST API and game state. It serves the static browser UI and exposes /api/* endpoints for player lifecycle, transactions, history, and reset. There is no database, background worker, authentication layer, or external service integration.
Dependencies are installed from requirements.txt; execution is python app.py.
In-memory game model
The backend maintains the authoritative collection of players and transaction history in process memory in app.py.
Core domain rules:
• Players have IDs, names, and balances.
• "BANK" is a special transaction endpoint with unlimited funds.
• Player senders must have sufficient balance.
• Invalid transfers are rejected before balances/history are changed.
• Reset clears both players and history.
This makes Flask process memory the transaction consistency boundary: state is suitable for one local game, not persistence, concurrent multi-process deployment, or recovery.
Player-management API stage
Player creation, listing, and deletion are implemented in app.py under:
• GET / POST /api/players
• DELETE /api/players/<id>
Creation validates required names, duplicate names, and starting balances. Removal updates the live player set. The frontend invokes these APIs from static/script.js and renders player-oriented controls in static/index.html.
Transaction execution stage
POST /api/transactions in app.py is the central business operation. It accepts source, destination, amount, and note; sources/destinations may be player IDs or "BANK".
Control flow is validation first—numeric positive amount, distinct endpoints, valid player references—followed by affordability checking for player senders, balance mutation, and transaction-history recording. This ordering prevents partial balance updates on rejected requests. GET /api/transactions returns history newest first.
Browser client
The UI is framework-free and has no build pipeline:
• static/index.html defines the application page.
• static/script.js performs API requests and updates rendered game state.
• static/style.css supplies presentation.
The client is a consumer of the Flask API rather than an independent state authority; refreshes can reconstruct its display from player and transaction endpoints while the server remains running.
Reset and verification
POST /api/reset in app.py starts a fresh game by clearing all in-memory domain state. Functional API behavior and rejection cases are exercised through tests/test_api.py, including balance preservation after insufficient-funds failures and transaction-history correctness.
Main entry points: app.py Flask entry & static serving · index.html Game page · script.js API client & rendering · style.css Presentation
Components 11
Browser client
- Game page
static/index.html - API client & rendering · Refreshes UI from server state.
static/script.js - Presentation
static/style.css
Flask process
Single process; all game state is ephemeral in memory.
- Flask entry & static serving · Serves the browser UI and owns all REST routes.
app.py - Player lifecycle API · Creates, lists, and removes live players.
app.py - Transaction API · Executes transfers and returns newest-first history.
app.py - Transfer validation & mutation · Validates before affordability checks, balance changes, and history recording.
app.py - Game reset API · Clears all live game state.
app.py - Players & balances · Authoritative player IDs, names, and balances.
app.py - Transaction history · Recorded only after successful transfers.
app.py - BANK endpoint · Unlimited-funds transaction endpoint.
app.py
Connections 14
- Game page → API client & rendering: loads
- Game page → Presentation: uses
- API client & rendering → Flask entry & static serving: fetches API and static UI
- Flask entry & static serving → Player lifecycle API: routes
- Flask entry & static serving → Transaction API: routes
- Flask entry & static serving → Game reset API: routes
- Player lifecycle API → Players & balances: creates, lists, deletes
- Transaction API → Transfer validation & mutation: POST transfer
- Transaction API → Transaction history: GET history
- Transfer validation & mutation → Players & balances: checks and mutates balances
- Transfer validation & mutation → Transaction history: records successful transfer
- Transfer validation & mutation → BANK endpoint: allows source or destination
- Game reset API → Players & balances: clears
- Game reset API → Transaction history: clears