Event Manager Web Application: Project Description

The Event Manager is a single-page web application (SPA) designed for a single user to efficiently create, view, update, and delete events. Each event will be characterized by its start and finish times, a title, and a detailed description. The application aims to provide a seamless and intuitive user experience with a focus on clear information presentation, straightforward event management, and real-time updates.

• Event Management: Full CRUD (Create, Read, Update, Delete) operations for events.
• Event Attributes: Each event will store:
  • id: Automatically generated by MongoDB.
  • startdt: Start date and time (chosen by user).
  • finishdt: Finish date and time (chosen by user).
  • title: A concise title for the event.
  • description: A detailed description of the event.
  • createdt: Timestamp of when the event was created (noted automatically).
  • updatedt: Timestamp of the last update to the event (noted automatically).
• Multiple Views: The application will offer several ways to visualize events:
  • Month Calendar View: A traditional calendar layout displaying events for the selected month.
  • Week View: A view showing events scheduled for the selected week.
  • Day View: A detailed view of events for a specific day.
• Single User Focus: The application is designed for use by a single individual to manage their personal or professional events.
• Real-time Updates: The UI will dynamically reflect changes made to events in the database without requiring a manual refresh, utilizing MongoDB Change Streams and Server-Sent Events (SSE).

The project leverages a modern JavaScript-centric stack with a local MongoDB database configured as a replica set.

Integrated Development Environment (IDE):

• Visual Studio Code (Version: 1.99.3)

Operating System:

• Windows 11 Pro N

Backend Technologies:

• Runtime Environment: Node.js (Version: 22.1.0)
• Web Framework: Express.js (Version: 5.1.0) (Note: Express is used for request routing, static file serving, and middleware, abstracted by custom server logic.)
• Module System: CommonJS

Frontend Technologies:

• Core Languages: HTML, CSS, JavaScript (Vanilla)
• Module System: ES Modules (ESM)
• Real-time Communication: Server-Sent Events (SSE)

Database:

• Database System: MongoDB (Local Instance, Version: 8.0.9), configured as a singular replica set.
• ODM (Object Data Modeling): Mongoose (Version: 8.14.1)
• Database Management Tool: MongoDB Compass (Version: 1.46.1)
• Real-time Feature: MongoDB Change Streams

• Single Repository: The entire application (frontend and backend) will reside in a single repository.
• Modularity: The codebase emphasizes high modularity.
  • Backend: Utilizes CommonJS modules. Core backend responsibilities are separated into distinct modules:
    • Database connection management.
    • Data access, business logic, and Change Stream integration.
    • Server setup (including static file serving), request handling (API routes), and real-time event feed (SSE) management.
    These modules are designed to offer clear, abstracted interfaces for use in the main application entry point (index.js).
  • Frontend: Employs ES Modules. UI components (ui.js) and client-side logic (client.js) will also be modular, exporting objects of the same name (e.g., ui.js exports a ui object).
• No Build Process: The project adheres to a "what you write is what you run" philosophy. There will be no bundling, compilation, transpilation, or minification steps involved.
• Code Style:
  • Indentation: Two spaces.
  • Semicolons: Avoid unnecessary semicolons in JavaScript.
  • Comments: Avoid using comments in code. Instead, write clean and understandable code that is self-documenting. If comments seem needed, write the documentation in a separate file.
  • Object/Array Formatting: Inline for short declarations, multi-line for longer ones to maintain readability.
• Real-time Data Synchronization:
  • Utilizes MongoDB Change Streams (requiring a replica set) to detect database modifications in the events collection.
  • Backend logic processes these detected changes.
  • Updates are pushed to connected clients via Server-Sent Events (SSE).
  • The frontend listens for these SSE messages and dynamically updates the UI, ensuring data consistency across views without manual refreshes.

The project will be organized within a root folder named crude-events-mongo.

📂crude-events-mongo/
├── 📂core/                # Backend modules and logic
│   ├── connect.js         # Mongoose connection setup (exports 'connect' function)
│   ├── db.js              # Exports 'useDB' function (takes mongoose, returns 'db' object with models/logic/changestream setup)
│   ├── server.js          # Exports 'startServer' function (takes port; starts server, returns 'server' object with request/SSE methods, serves static files)
│   └── ...                # Other backend modules as needed
├── 📂public/              # Frontend assets, served statically
│   ├── 📂js/              # Frontend JavaScript modules
│   │   ├── client.js      # Client-side API interaction and SSE listener logic (exports 'client' object)
│   │   └── ui.js          # DOM manipulation and UI components (exports 'ui' object)
│   ├── app.js             # Main frontend JavaScript file (wires 'ui.js', 'client.js')
│   ├── index.html         # Main HTML file for the SPA
│   └── style.css          # CSS styles for the application
├── index.js               # Main backend entry point (wires modules, configures server, starts server)
└── package.json           # Project metadata and dependencies

Backend (index.js in root):

• This file serves as the primary entry point for the backend.
• It will import and initialize modules from the core/ directory.
• Database Connection: It will first call the connect function from core/connect.js to establish and retrieve the Mongoose connection object.
• Database Logic Initialization: Then, it will call the useDB function from core/db.js, passing the Mongoose object to it. This yields the db object, which contains models, database interaction methods, and logic for setting up Change Stream listeners. This db object will be accessible to route handlers and Change Stream processing logic.
• Server Initialization and Start: Next, it will call the startServer function from core/server.js, passing the desired port. This function initializes an Express application, configures static file serving from the public folder, starts the HTTP server, and returns a server object.
• Route and Feeder Configuration: The index.js will then use the methods of the returned server object to define API routes and SSE feeders on the already running server:
  • For API routes: e.g., server.handleRequest('GET', '/api/events', (parsedBody) => db.getAllEvents()). The route handler callback, defined in index.js, accesses the initialized db object from its closure scope to interact with the database. The handleRequest method abstracts the underlying Express routing setup.
  • For SSE feeders: e.g., const feedEventsUpdate = server.getFeeder('/sse/events');. A Change Stream listener (which can be initiated and managed via the db object) will use this feedEventsUpdate(changeData) function to broadcast database changes to connected clients. The getFeeder method abstracts SSE setup over Express.

Frontend (app.js in public/):

• This file acts as the main script for the frontend.
• It will import and orchestrate modules from the public/js/ directory.
• It will use the ui object from public/js/ui.js to manage user interface updates and rendering.
• It will leverage the client object from public/js/client.js to handle communication with the backend API (e.g., fetching and sending event data using routes defined via server.handleRequest) and to establish an SSE connection (to an endpoint set up via server.getFeeder) for receiving real-time updates.

This structure and approach aim to create a maintainable, scalable, and understandable codebase, adhering to the specified technological and stylistic preferences, with a focus on delivering a responsive and dynamically updated user experience.