pxldigital/1eai-webtech-eindopdracht-rizzlers-matteo-dries-1

1. Overall shape

FilmTracker is a small, request-driven PHP monolith: each major feature is exposed as its own .php entrypoint, with shared state coming from PostgreSQL and shared session/auth behavior across pages.

2. Core runtime boundaries

The app runs on Apache/PHP 8+ and uses a single database connection file (db.php) plus shared styling (style.css). There is no separate application server, queue, or background worker layer.

3. Authentication and user boundary

register.php, login.php, and logout.php form the identity boundary. They create and use the logged-in user session that gates access to watchlist, reviews, stats, and export behavior.

4. Film management subsystem

search.php, watchlist.php, and film-detail.php are the film-centric workflows. They let a user search movies/series via the TMDB API, add items to a personal watchlist, update status/rating/review, and view detailed film data.

5. Statistics and reporting subsystem

stats.php is the analytics/reporting page. It aggregates watchlist data per user, renders charts in the browser, and also doubles as a lightweight REST-style JSON endpoint for external clients via ?api=1.

6. Export subsystem

export.php generates a PDF export of the user’s watchlist using the bundled FPDF library. This is the main “document generation” boundary in the repository.

7. Persistence model

The data model is simple and centered on two tables: users and watchlist. users holds account identity and credentials; watchlist stores per-user film records including TMDB ID, title, poster, status, rating, review, and timestamps.

8. Data flow for film search

A typical flow is: browser searches in search.php → PHP calls TMDB → results are shown client-side → selected film is inserted into watchlist in PostgreSQL. This is the main integration path between the external movie service and local persistence.

9. Data flow for watchlist updates

watchlist.php acts as the user’s control panel for changing item state. Updates such as status changes, deletions, and rating/review edits are persisted server-side and usually reflected back through Ajax-driven UI updates.

10. Client-side interaction layer

The front end uses jQuery 3.7 for Ajax and DOM updates, plus custom JavaScript for features like debounce, star rating, and input escaping. stats.php also uses Chart.js to visualize aggregated data.

11. External-device/API boundaries

The repo exposes two small integration points for non-browser clients:

- search.php supports action=remote_add to add a film via POST

- stats.php?api=1&user_id=... returns summary statistics as JSON

These are the only explicit API-style endpoints in an otherwise page-based app.

12. Vendored dependency boundary

The fpdf/ directory is a vendored third-party library, not core app logic. It contributes the PDF generation capability and should be treated as an external dependency boundary in any architecture diagram.

13. Practical architecture summary

The cleanest diagram is: browser/UI → PHP page/controller → shared session/db layer → PostgreSQL, with side integrations to TMDB for film metadata and to FPDF/Chart.js/jQuery for export and interactive UI/reporting.