Issue: Core Action Logic Fragmented Across Multiple PHP Endpoints (Issue: 3)

[alwin-m]

Issue: Fragmented Action Logic Across Multiple PHP Action Files

Date: 2025-11-21
Time: 20:00 IST
Assigned to: Alwin Madhu
Status: Open

Summary

As the Scream platform continues to expand, the architecture for handling user actions (posting, liking, commenting, and future features) is becoming increasingly fragmented. Each interaction currently requires its own dedicated action file. This separation works for small systems, but at scale it introduces maintainability problems, structural inconsistencies, and unnecessary complexity.

This issue documents the challenge and establishes the need for a more organized request-handling strategy.

---

Problem Description

Scream’s current design requires dedicated PHP action files for:

• Creating new posts
• Liking/unliking posts
• Submitting comments
• Tracking views
• Future interactions (bookmarking, reporting, following, etc.)

While this approach works during early development stages, it introduces a critical architectural issue:

1. Fragmentation of Core Logic

Each user interaction becomes a standalone action file. Over time, this results in a scattered backend structure. When the project grows, core operations will be spread across many small files, making it harder to:

• Trace logic flow
• Apply updates consistently
• Debug user interactions
• Ensure security and validation across all actions

2. Tight Coupling With the Main Page (index.php)

The main feed page must communicate with multiple action files:

• post_action.php
• like_action.php
• comment_action.php
• Etc.

Each action file introduces its own logic, session access, and database operations. This increases the chances of:

• Inconsistent session handling
• Misaligned database queries
• Redundant code being repeated in multiple places

3. Scalability Limitations

As Scream aims to support real usage with hundreds or thousands of users, fragmented action logic becomes a performance bottleneck:

• Multiple small action files increase request overhead
• Harder to optimize caching, rate-limiting, and validation
• Difficult to scale backend decisions uniformly

4. Architectural Uncertainty

There are two available paths:

Option A — One Unified Action Controller

Create a single action entry point such as:

action.php?action=post

This centralizes backend logic into a shared controller.
But this approach requires more complex routing logic and structured programming.
It is harder for beginners and adds additional learning overhead.

Option B — Separate Action Files (Current Plan)

Create distinct action pages:

post_action.php
like_action.php
comment_action.php

This is simpler for learning and debugging.
But it increases fragmentation long-term.

Current Decision

To maintain clarity, especially during the learning and early-building stage, we will proceed with separate action pages for each user action.

This issue exists to track the fact that this architecture may create long-term challenges, and may need refactoring when the project reaches a larger scale.

---

Why This Issue Is Important

If left unaddressed, this problem can lead to:

• Difficulty scaling beyond small user groups
• Bloated backend directory structure
• Troubleshooting delays due to scattered logic
• Higher risk of inconsistent data handling
• Harder migration to an API-based backend in the future

This issue defines the problem clearly so that future contributors understand the architectural implications and can prepare for possible refactoring.

---

Affected System Areas

• Backend PHP action logic
• Session handling across multiple pages
• Database interaction consistency
• Index/Home page integration

---

Proposed Direction (Not a Solution — Just Documentation)

The current plan is to:

• Keep separate action pages for each interaction
• Reevaluate the structure after MVP stabilizes
• Consider refactoring into a unified controller or API endpoint later

This decision supports beginner-friendly development while acknowledging future challenges.

---

Assignee

Alwin Madhu
Email: [alwinmadhu4060@gmail.com]

Project Owner & Lead Developer