MiniFlix is a web-based streaming service that streamlines the core functionalities of platforms like Netflix, offering content streaming, browsing, user management, and a wishlist feature with a responsive design.

The system's architecture is visualized through a comprehensive screen flow, an Entity-Relationship Diagram (ERD), and detailed sequence diagrams for key functionalities. The screen flow outlines user navigation across various pages: a non-logged-in landing page, authentication pages (login, signup), the main home screen displaying content, content-related pages (search results, genre-filtered lists, content details, video player), and user-specific pages (My Page, Wishlist, Account Info). All content-related pages and user pages allow navigation back to the home screen.

The database schema, defined by the ERD, comprises six main entities:

• Users: Stores user information including id (PK), email (login ID), password_hash, name, created_at, updated_at, and is_active (account status).
• Contents: Holds details for each video content, such as id (PK), title, description, thumbnail_url, video_url, duration, release_year, created_at, and updated_at.
• Genres: Defines content categories with id (PK), name, and description.
• ContentGenres: A mapping table (junction table) linking Contents and Genres with id (PK), content_id (FK), and genre_id (FK).
• Wishlists: Records contents saved by users, including id (PK), user_id (FK to Users), content_id (FK to Contents), and created_at.
• ViewingHistories: Tracks user viewing activity, containing id (PK), user_id (FK to Users), content_id (FK to Contents), watch_duration, last_position, watched_at, and is_completed.

Relationships are defined as follows: A User can have multiple Wishlists and ViewingHistories. A Content can be in multiple Wishlists, multiple ViewingHistories, and be categorized by multiple ContentGenres. A Genre can classify multiple ContentGenres.

The core methodology is detailed through several sequence diagrams illustrating interactions between the Client (browser), Backend API Server, Database (DB), and Media Storage.

1. User Registration: The Client sends email, password, and name to the API. The API validates the data, queries the Users table for email duplication. If unique and valid, the password is hashed, and the user's information (email, password\_hash, name, created\_at, is\_active=1) is saved to the Users table. Responses include 409 Conflict (email duplicate), 400 Bad Request (validation failure), or 201 Created on success, followed by redirection to the login page.

2. Login: The Client sends email and password. The API queries the Users table for the user's information (id, password\_hash, name, is\_active) by email. If the user doesn't exist (401 Unauthorized) or is inactive (403 Forbidden), an error is returned. If found, the API verifies the provided password against the stored password_hash. Upon successful verification, a JSON Web Token (JWT) containing user ID and name is generated and returned with 200 OK along with basic user info. The Client stores the JWT (e.g., in localStorage/cookies) and redirects to the home screen.

3. Home Screen Content Load: When accessing the home screen, if logged in, the Client sends an authenticated request (with JWT) to the API. The API validates the JWT. If valid, it queries the Contents table for basic content information (id, title, thumbnail\_url, release\_year). It also queries the Wishlists table to retrieve the user's liked content IDs and then merges this information to add is_liked status to each content item before returning the 200 OK response. If the JWT is invalid (401 Unauthorized), the client is redirected to login. For non-logged-in users, the Client sends an unauthenticated request, and the API directly returns content basic info from the Contents table without is_liked status.

4. Content Search: The Client sends a search query (and an optional JWT). The API queries the Contents table for titles matching LIKE '%검색어%'. If logged in, the API also fetches the user's Wishlists to indicate liked content in search results. The API returns 200 OK with the matching content list (or an empty array if no results).

5. Genre Filtering: The Client first requests a list of genres from the API, which queries the Genres table and returns them for UI display. Upon user selection of a genre, the Client requests content for the chosen genre_id (with optional JWT). The API joins Contents and ContentGenres tables to filter by genre_id. Similar to search, if logged in, Wishlists are checked to add is_liked status to the filtered content list.

6. Content Details View: When a content thumbnail is clicked, the Client requests detailed information for a content_id (with optional JWT). The API queries Contents, ContentGenres, and Genres tables to retrieve full content details and associated genres. If logged in, it also checks the Wishlists table for the content's like status and ViewingHistories for the last_position (last watched point). The API returns 200 OK with detailed info, like status, and last position (if applicable).

7. Content Playback: If a user attempts to play content while not logged in, they are redirected to the login page. If logged in, the Client sends a playback request (with content_id, JWT). The API validates the JWT, retrieves video_url from Contents and last_position from ViewingHistories. The API then returns the streaming URL and last position. The Client requests the video stream from the Media Storage. During playback, the Client periodically updates the API (every 30 seconds) with current_position which the API saves to ViewingHistories. Upon playback termination (pause, window close), the Client sends a final update (final\_position, watch\_duration, is\_completed), which the API saves.

8. Wishlist Toggle: If not logged in, clicking the like button redirects to login. Otherwise, the Client sends a toggle request (with content_id, JWT). The API validates the JWT and checks the Wishlists table for the current like status. If already liked, it deletes the entry from Wishlists (200 OK, is_liked: false). If not liked, it adds an entry to Wishlists (201 Created, is_liked: true). The Client updates its UI accordingly.

9. Wishlist View: From My Page, the Client requests the wishlist (with JWT). The API validates the JWT, then joins Wishlists and Contents tables to retrieve the details of all liked contents for the user. Returns 200 OK with the list of contents or an empty array.

10. Account Information View: From My Page, the Client requests account info (with JWT). The API validates the JWT, queries the Users table for the user's email, name, and created_at, and returns 200 OK with this information.

11. Account Information Update: The Client sends updated name or password (and current password for verification, JWT). The API validates the JWT and verifies the current_password against the stored password_hash in Users. If the current password matches and new data is valid (new password is hashed if provided), the Users table is updated (name, password_hash, updated_at). Returns 200 OK on success, 403 Forbidden for incorrect current password, or 401 Unauthorized for invalid JWT.

The project utilizes a modern technology stack:

• Frontend: TypeScript, React, Next.js, Zustand (state management), React Query (server state management), TailwindCSS (styling), and Axios (HTTP client).
• Backend: Golang with the Gin framework, MySQL as the database, JWT for authentication, and Swagger for API documentation.
• Deployment: Docker Compose for easy setup and management.

The application can be accessed via http://localhost:3000 for the frontend, http://localhost:8080 for the backend API, and http://localhost:8080/swagger/index.html for the API documentation, enabling both local development and deployment.