Skip to content

rah3/youtubeServer.github.io

Repository files navigation

📊 3-YoutubeServer

A functional YouTube Dashboard prototype running on Node.js and Express, developed within a WSL (Windows Subsystem for Linux) environment. This application allows users to fetch live data from the YouTube Data API v3, embed video players, manage a favorites list, and export data locally.

🚀 Features

  • RESTful Backend: Express server handling API requests and serving static assets.
  • Live YouTube Integration: Fetches real-time video metadata (Title, Channel, Thumbnail, ID).
  • Dynamic UI: Responsive grid layout with embedded <iframe> players.
  • State Management: Client-side favorites system (Add/Remove functionality).
  • Event Delegation: High-performance JavaScript event handling (No onclick attributes).
  • Data Export: Generates and downloads a .txt file of favorites using Browser Blobs.

🛠 Tech Stack

  • Runtime: Node.js
  • Framework: Express.js
  • Frontend: HTML5, CSS3 (Flexbox/Grid), Modern JavaScript (ES6+)
  • Environment: WSL (Ubuntu)
  • API: YouTube Data API v3

📦 Installation & Setup

  1. Clone the Repository
git clone <your-repo-url>
cd 3-YoutubeServer
  1. Install Dependencies
npm install
  1. Environment Variables Create a .env file in the root directory and add your YouTube API Key:
API_KEY=your_actual_api_key_here
PORT=3000
  1. Start the Server
node server.js

The application will be available at http://localhost:3000.


📂 Project Structure

3-YoutubeServer/ ├── node_modules/ # Installed npm packages ├── public/ # Static frontend assets │ ├── client.js # Frontend logic (State & Events) │ ├── index.html # Main HTML structure │ └── styles.css # UI styling & Grid layout ├── .env # Environment variables (API Key) ├── package.json # Project metadata & dependencies ├── package-lock.json # Locked dependency versions ├── README.md # Project documentation ├── server.js # Main Express server entry point ├── testKey.js # Utility script for API key validation └── YouTubeService.js # Service layer for YouTube API interactions


🧠 Key OOSE Concepts Applied

1. Separation of Concerns

The project is divided into Client (UI/State) and Server (Data Fetching/Security). This ensures that API keys remain hidden on the backend while the frontend focuses on user interaction.

2. Event Delegation

Instead of attaching listeners to every video card, a single listener is attached to the parent container. This optimizes memory usage and handles dynamically generated content.

3. Asynchronous Programming

Extensive use of async/await and the fetch API to handle non-blocking network requests, ensuring a smooth user experience during data retrieval.

To help you stand out in your OOSE assignment, here is a detailed Architecture and Data Flow section for your README.md. This explains how you transitioned from a simple script to a modular, professional system.


🏗 System Architecture & Data Flow

This project follows a Client-Server-Service architecture. By separating the logic into specific layers, the system is easier to maintain, test, and scale.

1. Architectural Layers

  • Service Layer (YouTubeService.js): Encapsulates the communication with the YouTube Data API v3. It handles authentication (API Key) and parameter formatting.
  • Controller Layer (server.js): Acts as the middleman. It receives requests from the frontend, calls the YouTubeService, and sends the processed data back as JSON.
  • View/Client Layer (public/): A modern, event-driven frontend. It handles user interactions, manages the local state (Favorites), and renders the UI dynamically.

2. The Data Journey (Request/Response Cycle)

When a user searches for a video or refreshes the gallery, the following sequence occurs:

  1. User Action: User clicks the "Refresh" button in the browser.
  2. Client Request: client.js triggers loadGallery(), sending a GET request to the backend /atemlos endpoint.
  3. Server Processing: server.js receives the request and invokes the fetch logic within YouTubeService.js.
  4. External API Call: The server communicates with Google's servers using the secure API_KEY.
  5. Data Transformation: The raw YouTube response is simplified into a clean JSON array.
  6. UI Rendering: client.js receives the JSON, maps it into HTML "Video Cards," and injects them into the DOM.

3. State & Event Management

  • Event Delegation: To optimize performance, the application uses a "Master Listener" on parent containers (like #results and #favorites-list). This prevents memory leaks and ensures that even newly added videos are immediately interactive.
  • Client-Side State: The favorites list is managed as a JavaScript array in memory. This allows for instant UI updates (Add/Remove) without requiring a page reload or additional server calls.

🛠 Usage of Utility Scripts

  • testKey.js: A standalone diagnostic tool used during development to verify that the .env file is correctly loaded and the YouTube API Key has the necessary permissions.
  • .env: Used to store sensitive credentials. Note: This file is excluded from version control to prevent security leaks.

Final Project Checklist for Submission

  1. **Run node testKey.js** to ensure your environment is healthy.
  2. Start the server with node server.js.
  3. Test the "No onclick" flow: Add a video, remove a video, and download the .txt file to ensure the data flow is perfect.

💡 Lessons Learned & Engineering Insights

1. From "Inline" to "Event-Driven"

Transitioning from onclick attributes to a centralized Event Delegation model significantly improved the project's scalability. By attaching listeners to parent containers rather than individual elements, the application now handles dynamically generated search results efficiently, reducing memory overhead and keeping the HTML structure "clean" and focused purely on content.

2. The Power of the Service Pattern

Moving the YouTube Data API logic into its own module (YouTubeService.js) simplified the server.js file. This modularization (Decoupling) makes the code easier to maintain; if the YouTube API changes, only the service file needs updating, leaving the rest of the application logic untouched.

3. State Management without a Database

Managing the "Favorites" list as an internal array within client.js taught the importance of Client-Side State. It allows for an "optimistic" and instant user interface, where items are added or removed without waiting for a server response, providing a modern, "App-like" feel to a web page.

4. Navigating the WSL Environment

Developing this project within WSL (Ubuntu) required a deeper understanding of environment variables (.env) and networking. Ensuring the Node.js server correctly bridges from the Linux subsystem to the Windows browser was a key takeaway in cross-platform development workflows.


🧪 Testing Protocol

To ensure system stability, the following testing steps were implemented:

  • API Key Validation: Using testKey.js to confirm connectivity before launching the main server.
  • Sanitization Testing: Using replace(/"/g, '&quot;') to ensure video titles with special characters don't break the HTML data-attributes.
  • Resource Management: Implementing URL.revokeObjectURL(url) during the download process to prevent memory leaks in the browser.

📝 License

This project is for educational purposes as part of an OOSE module.

About

A specialized server designed to aggregate all available recordings of the song "Atemlos" by German artist Helene Fischer.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published