System overview

The Community Center of Abu Tor website implements a classic three-tier architecture, consisting of an Application layer, Backend services layer, and Database layer. This separation of concerns allows for modular development, easier maintenance, and scalability as user needs grow. The system follows a traditional client-server model, using standard HTTP requests and responses for communication between tiers. The data flows linearly from the Application through the Backend to the Database for storage operations, and in reverse for retrieval operations. This unidirectional flow simplifies debugging and enhances security by ensuring that the user interface never directly accesses the database. All business logic is centralized in the Backend layer, which serves as the system's core processing unit.

System Components

Application Layer

The Application layer is built with native HTML, CSS, and JavaScript, split into two primary interfaces:

1. Admin Interface
   • Form Management Module: HTML forms with JavaScript validation for managing different types of forms.
   • News Management Module: Content editor interface for publishing, editing, and removing community news.
   • Class Management Module: Calendar-based interface for scheduling and managing community classes.
2. User Interface
   • Content Viewing Module: Static and dynamically loaded HTML pages displaying news articles and class information.
   • Event Registration Module: Form-based interfaces for browsing events and submitting registration requests.
   • Complaint Submission Module: HTML forms with client-side validation for submitting community feedback.

[!NOTE] The Application layer uses vanilla JavaScript for DOM manipulation and form handling, with CSS for responsive design to ensure accessibility across devices. AJAX requests are used to communicate asynchronously with the Backend API.

Backend Layer

The Backend layer contains several functional modules that process requests from the Application layer:

1. Authentication Module

   • Handles admin login functionality.
   • Validates tokens for authenticated requests.
   • Performs identity verification.
   • Manages user sessions.

2. Event Management Module

   • Retrieves event listings from the database.
   • Processes event creation requests.
   • Handles event updates and deletions.
   • Maintains event state across the system.

3. Event Registration Module

   • Processes join requests from users.
   • Retrieves pending registration requests for admin review.
   • Handles request approval workflow.
   • Updates registration status.

4. News Management Module

   • Retrieves news articles from the database.
   • Processes news creation, updates, and deletions.
   • Handles content formatting and metadata.

5. Complaint Processing Module

   • Handles complaint submissions from users.
   • Routes complaints to appropriate administrators.
   • Manages complaint status updates.
   • Archives resolved complaints.

The Backend is implemented using server-side technologies like Node.js, Bcrypt, Mango, JWT, and Express, responding to HTTP requests from the client application and providing both data and rendered HTML fragments as needed.

Database Layer

The layer which all kinds of storing/deleting operations are operating, where all the tables exist.

[!NOTE] The database implements a relational structure with the Events table connected to the EventJoins table through the EventID foreign key relationship, allowing for tracking registrations associated with specific events.

This is the Data Flow:

Database Design

Database Schemas

1. Users Table

   • Username (STRING): Unique identifier for system users.
   • Password (STRING): Securely hashed user passwords.
   • Role (STRING): User permission level (admin/regular).
   • Created At (DATE): Account creation timestamp.

2. News Table

   • Image (String): Image for the news.
   • Title (STRING): News article headline.
   • Description (STRING): Body content of news articles.
   • Date (DATE): Publication date.

3. Events Table

   • EventID (INT): Primary key identifier.
   • Image (STRING): Path to event promotional image.
   • Description (STRING): Detailed event information.
   • Type (STRING): Category of event.
   • Date (DATE): Scheduled event date.
   • Created At (DATE): Record creation timestamp.

4. EventJoins Table

   • EventID (INT): Foreign key linking to Events table.
   • Name (STRING): Registrant's name.
   • Email (STRING): Contact email.
   • PhoneNo (STRING): Contact phone number.
   • Reason (STRING): Purpose for joining event.
   • Is Confirmed (BOOLEAN): Registration approval status.
   • Created At (DATE): Registration submission timestamp.

5. Complaints Table

   • Name (STRING): Complainant's name.
   • Email (STRING): Contact email.
   • Phone (STRING): Contact phone number.
   • Description (STRING): Complaint details.
   • Images (STRING): Paths to supporting images.
   • Is Solved (BOOLEAN): Resolution status.
   • Created At (DATE): Submission timestamp.

Entity Relationship Diagram (ERD)

Sequence Diagrams

Admin adding new events/news

User filling a form and register it

This architecture provides a robust foundation for the Community Center website, allowing for efficient operation while maintaining system security through proper separation of concerns between the presentation layer, business logic, and data storage.