ponnamsrisai/parking_app

1. Overall shape

- This is a small monolithic Flask web application for parking management.

- All major concerns live in one repo: request handling (app.py), data models (models/), form validation (controllers/forms.py), database bootstrap (db_schema.py), and server-rendered UI (templates/ + static/).

2. Primary runtime boundary

- The browser talks to the Flask server over HTTP.

- Flask renders HTML using Jinja2 templates, so the frontend is not a separate SPA; it is server-side rendered pages with some client-side styling/visualization.

3. Request handling layer

- app.py is the application entry point and likely contains:

- Flask app configuration

- route definitions

- login/session handling

- role-based redirects for admin vs user

- business logic for booking, releasing, and summary pages

- This is the main orchestration layer that connects web requests to the database and templates.

4. Domain/data layer

- models/models.py defines the persistent entities and relationships:

- User

- Admin

- ParkingLot

- ParkingSpot

- Booking

- The schema supports:

- one parking lot to many parking spots

- users creating bookings against spots

- booking history with timestamps and cost calculation

- Persistence is through Flask-SQLAlchemy with a local SQLite database.

5. Authentication and authorization

- The app uses Flask-Login for session-based authentication.

- Passwords are stored as hashes using Flask-Bcrypt.

- The system is role-based:

- Admin can manage lots, spots, users, and summaries

- User can book/release spots and view personal history

- Unauthorized access is handled by a dedicated error_403.html page, indicating explicit access control boundaries.

6. Form validation boundary

- controllers/forms.py contains the WTForms/Flask-WTF definitions for user input.

- This is the validation layer between browser-submitted data and the database/business logic.

- It likely covers login/signup, parking lot creation, booking/release actions, and profile editing.

7. Admin subsystem

- The admin-facing pages are:

- admin_dashboard.html

- admin_summary.html

- admin_users.html

- admin_parking_spot.html

- add_parking_lot.html

- This subsystem is responsible for:

- creating and managing parking lots

- observing occupancy and utilization

- viewing registered users

- seeing aggregated statistics

8. User subsystem

- The user-facing pages are:

- user_dashboard.html

- user_book.html

- user_release.html

- user_summary.html

- edit_profile.html

- This subsystem handles:

- account creation and sign-in

- booking an available parking spot

- releasing an occupied spot

- showing individual parking history, duration, and total price

9. Data flow for booking and release

- User action starts in a template form.

- Flask-WTF validates the request.

- app.py checks the authenticated user and spot availability.

- The ORM updates:

- spot status

- occupancy counts in the parking lot

- booking record with entry/exit time and price

- The response is a redirected dashboard or summary page.

10. Reporting and visualization

- The summary pages (admin_summary.html, user_summary.html) are the reporting boundary.

- The README mentions Chart.js, so charts are likely embedded in these templates to visualize parking usage and statistics.

- This is a read-heavy flow that aggregates data from bookings/lots rather than creating new entities.

11. Database initialization

- db_schema.py is separate from the runtime app and is used to create the schema and seed the initial admin account.

- That makes the architecture split between:

- startup/bootstrap concerns in db_schema.py

- operational request handling in app.py

12. Presentation layer

- templates/base.html is the shared layout, with other pages extending it.

- static/css/styles.css provides custom styling, while Bootstrap is used for responsive layout.

- static/images/ contains branding/assets, not core logic.

13. Key architectural boundaries to show in a diagram

- Browser/UI → Flask routes

- Routes → form validation

- Routes → ORM models/database

- Admin-only flows vs user-only flows

- Initialization script → database schema/seed data

- Summary/reporting views → aggregated booking and occupancy data

14. Implementation style

- This repo is a traditional server-rendered CRUD-style application with role-based access control.

- There are no separate microservices, message queues, or external APIs in the visible structure.

- The main architectural idea is a clean separation between web pages, validation, persistence, and role-specific workflows.