akshay/Url_monitor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added AI_LOG

Browse Source
This commit is contained in:
Vadher
2026-07-19 17:07:54 +05:30
parent 5db5d5c7d3
commit 609a4efcbc
2 changed files with 357 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AI_LOG.md
+169
View File
@@ -0,0 +1,169 @@
# AI_LOG.md
# AI Collaboration Log
This document summarizes how AI tools were used during the development of this project, the decisions made, and the lessons learned throughout the implementation.
---
# AI Tech Stack
The following AI tools were used during development:
- ChatGPT (GPT-5.5)
- GitHub Copilot (VS Code Chat)
- Google Gemini
Each tool was used for different purposes, including brainstorming, backend implementation, debugging, architecture discussions, and documentation.
---
# Development Journey
## 1. Choosing the Frontend
Initially, I was unsure whether to build the frontend using React or a simple static HTML page.
Since the assignment required an MVP and the frontend only needed to display monitoring results and receive WebSocket updates, I decided to keep it simple and use a static HTML/JavaScript frontend served through Express.
This reduced unnecessary complexity and allowed me to focus more on the backend implementation.
---
## 2. Designing the Project Structure
One of my first prompts to GitHub Copilot was to generate a project directory structure.
The initial suggestion contained many folders, services, configuration files, and abstractions that felt unnecessary for a small MVP.
Instead of following that structure directly, I simplified it significantly and ended up with a much smaller and easier-to-maintain project.
Final structure:
```text
backend/
database/
models/
routes/
utils/
app.js
web_socket_server.js
frontend/
index.html
scripts.js
```
This structure was sufficient for the assignment while remaining easy to understand.
---
# Prompts That Shaped the Project
Examples of prompts used during development include:
- "Generate a simple folder structure for a Node.js URL monitoring application."
- "Implement a WebSocket server that broadcasts URL health updates."
- "How should I organize Express routes and controllers?"
- "How can I dynamically update HTML using WebSockets?"
- "Generate a Docker Compose configuration for this application."
- "Create a professional README for this project."
These prompts were used as starting points rather than copied directly into the final implementation.
---
# Course Corrections
AI significantly accelerated development, but many generated solutions required refinement before they became production-ready.
## Simplifying the Architecture
The first suggested architecture was considerably more complex than necessary for the scope of this assignment.
I simplified the project by reducing unnecessary layers and keeping only the components required for the MVP.
---
## WebSocket Communication
While implementing WebSockets, I learned the difference between sending messages to a single client versus broadcasting to all connected clients.
For example:
- `ws.send()` sends data to a single connected client.
- Iterating through `wss.clients` and calling `client.send()` broadcasts updates to every connected client.
This understanding helped implement real-time monitoring correctly.
---
## Asynchronous Processing
During implementation, I initially used asynchronous iteration in a way that caused the "finished" event to be emitted before all URL checks had completed.
After debugging, I changed the implementation to wait for all monitoring requests before broadcasting the completion event.
---
## File Path Management
Initially I used hardcoded relative file paths.
Through AI discussions and debugging, I learned that using Node.js `path.join()` together with `__dirname` produces more reliable and portable file paths, especially when running inside Docker or from different working directories.
---
## Dynamic UI Updates
Instead of requiring the user to refresh the page after adding a new URL, I implemented:
- writing the URL into `urls.json`
- broadcasting the update through WebSockets
- dynamically adding the new row to the table
This allows new URLs to appear immediately without refreshing the browser.
---
# Development Focus
The project intentionally prioritizes backend engineering over frontend styling.
Most development effort was spent on:
- REST API design
- WebSocket communication
- Health monitoring logic
- Monitoring history
- Dynamic updates
- Error handling
- Dockerization
- Project documentation
The frontend was intentionally kept minimal because the primary objective of the assignment was demonstrating backend architecture and real-time communication.
---
# Key Learnings
During this project I improved my understanding of:
- Express application structure
- REST API design
- WebSocket communication
- Real-time frontend updates
- Broadcasting messages to multiple clients
- Asynchronous programming in Node.js
- Managing JSON-based persistence
- File path handling using `path.join()`
- Dockerizing a Node.js application
- Structuring a maintainable backend project
---
# Reflection
AI greatly accelerated development by helping generate initial implementations, explain unfamiliar concepts, and assist with debugging.
However, every generated solution was reviewed, simplified where necessary, and adapted to match the project requirements. Rather than accepting AI-generated code as-is, I treated it as a collaborative tool to explore alternatives, understand implementation details, and make informed engineering decisions.
README.md
+188
View File
@@ -2,6 +2,10 @@
A lightweight **URL Health Monitoring** application built with **Node.js, Express, WebSocket, Axios, and Docker**. The application periodically checks the health of registered URLs and updates the frontend in real time using WebSockets. A lightweight **URL Health Monitoring** application built with **Node.js, Express, WebSocket, Axios, and Docker**. The application periodically checks the health of registered URLs and updates the frontend in real time using WebSockets.
# Live demo (deployed on Render)
### https://url-monitor-fsw7.onrender.com
## Features ## Features
- Real-time URL health monitoring - Real-time URL health monitoring
@@ -276,6 +280,76 @@ setInterval(async () => {
--- ---
## Testing Steps
Follow the steps below to verify that the application correctly detects both **UP** and **DOWN** states in real time.
### 1. Start the URL Health Monitor
Launch the application using Docker (or run it locally).
```bash
docker compose up
```
### 2. Create a Test Server
Duplicate `backend/app.js` and save it as `backend/app-test.js`.
Change the port to **3001** (or any unused port):
```javascript
const PORT = 3001;
```
Start the test server:
```bash
node backend/app-test.js
```
### 3. Register the Test URL
Add the following URL using either:
- the **Add URL** form in the top-right corner of the dashboard, or
- by appending it directly to `backend/database/urls.json`.
```
http://127.0.0.1:3001
```
A new row will be added to the monitoring table automatically, and within the next polling cycle its status should change to:
```
Status: UP
```
No page refresh is required.
### 4. Verify the DOWN State
Stop the test server:
```bash
Ctrl + C
```
Within the next monitoring interval, the dashboard will automatically update the same URL to:
```
Status: DOWN
```
This confirms that:
- URL health checks are performed periodically.
- Status changes are detected automatically.
- WebSocket updates are pushed to the frontend in real time.
- No manual page refresh is required.
#
# Docker Support # Docker Support
The project can be run using Docker and Docker Compose. The project can be run using Docker and Docker Compose.
@@ -314,6 +388,120 @@ The `backend/database` directory can be mounted as a Docker volume so that `urls
--- ---
# Deployment Sketch
## Current MVP Deployment
The application is currently deployed on **Render** as a single Node.js web service.
The Express application serves:
- Static frontend (`index.html`, `scripts.js`)
- REST API endpoints
- WebSocket server
- URL health monitoring service
Monitoring data is currently stored in JSON files (`urls.json` and `db.json`) for simplicity.
### High-Level Architecture
```text
+----------------------+
| Web Browser |
+----------+-----------+
|
HTTP / WebSocket
|
v
+------------------------------------+
| Render Web Service |
|------------------------------------|
| |
| Express.js Application |
| |
| +------------------------------+ |
| | Static Frontend | |
| | index.html | |
| | scripts.js | |
| +------------------------------+ |
| |
| +------------------------------+ |
| | REST API | |
| | GET /api/url | |
| | POST /api/url/register | |
| +------------------------------+ |
| |
| +------------------------------+ |
| | WebSocket Server | |
| | Real-time Status Updates | |
| +------------------------------+ |
| |
| +------------------------------+ |
| | Health Check Service | |
| | Axios Polling | |
| +------------------------------+ |
| |
| backend/database/ |
| urls.json db.json |
+------------------------------------+
```
---
# Future Cloud Deployment
For a production-ready deployment, I would separate the application into managed cloud services.
```text
+----------------------+
| Web Browser |
+----------+-----------+
|
HTTPS / WSS
|
v
+------------------------+
| Cloud Load Balancer |
+-----------+------------+
|
v
+-------------------------------+
| Dockerized Node.js App |
|-------------------------------|
| Express API |
| Static Frontend |
| WebSocket Server |
| Health Monitoring Service |
+---------------+---------------+
|
+----------------+----------------+
| |
v v
+---------------------+ +----------------------+
| PostgreSQL/MongoDB | | Object Storage |
| Registered URLs | | Monitoring History |
+---------------------+ +----------------------+
```
## Infrastructure-as-Code (Example)
A minimal Docker-based deployment could be provisioned using Docker Compose:
```yaml
version: "3.9"
services:
url-health-monitor:
build: .
ports:
- "3000:3000"
restart: unless-stopped
volumes:
- ./backend/database:/app/backend/database
```
In a production cloud environment, the JSON files would be replaced by a managed PostgreSQL or MongoDB database, Docker images would be deployed automatically through a CI/CD pipeline, and HTTPS would be provided by the cloud platform.
# Future Improvements # Future Improvements
- Delete registered URLs - Delete registered URLs