Project Scripts

Relevant source files

The following files were used as context for generating this wiki page:

• package.json
• server.js
• seed.js
• model_database.py
• APP/models/model.model.js
• public/index.html
• APP/config/db.config.js
• APP/models/index.js

The LostData project is managed through a collection of scripts that handle backend services, database management, and data seeding. The primary application is a Node.js server built with Express, which serves a web interface and provides a REST API for managing a "Model" database stored in MongoDB.

Additionally, the project includes a standalone Python script for managing a local JSON-based version of the model database via a command-line interface, and a Node.js script for seeding the primary MongoDB database with initial data. These scripts collectively provide the full functionality for running, managing, and populating the application.

Node.js Backend Server (server.js)

The core of the application is an Express.js server that handles API requests, user sessions, and serves the frontend. It integrates with a MongoDB database to provide persistence for "model" data.

Sources: server.js, package.json, APP/models/index.js

Architecture and Middleware

The server is configured with several middleware components to handle common web application tasks:

• cors: Enables Cross-Origin Resource Sharing.
• express.json & express.urlencoded: Parse incoming JSON and URL-encoded payloads.
• express-session: Manages user sessions for authentication. A user's role (admin or chatter) is determined by their email address format.
• multer: Handles multipart/form-data, used for file uploads (specifically CSV imports).
• express.static: Serves static files from the public directory.

The server connects to a MongoDB database using the connection string from process.env.MONGODB_URI or a local default.

Sources: server.js:2-25, APP/config/db.config.js:2-3

API Endpoints

The server exposes a RESTful API for managing user authentication and model data. Access to modification endpoints (POST, PUT, DELETE) and data export/import is restricted to admin users.

This diagram illustrates the general flow for an incoming API request.

The following table summarizes the key API endpoints.

Method	Endpoint	Description	Admin Only
POST	/api/login	Authenticates a user based on email and creates a session.	No
POST	/api/logout	Destroys the current user session.	No
GET	/api/models	Retrieves a sorted list of all models.	No
GET	/api/models/:id	Retrieves a single model by its ID.	No
POST	/api/models	Creates a new model.	Yes
PUT	/api/models/:id	Updates an existing model by its ID.	Yes
DELETE	/api/models/:id	Deletes a model by its ID.	Yes
GET	/api/export/json	Exports all models as a JSON file.	Yes
GET	/api/export/csv	Exports all models as a CSV file.	Yes
POST	/api/import/csv	Imports models from an uploaded CSV file.	Yes

Sources: server.js:27-142, public/index.html:158-179

Authentication and Authorization

Authentication is handled via sessions. A user logs in by POSTing their email to /api/login. The server assigns a role of admin if the email ends with @admin.com, and chatter otherwise. This role is stored in the session.

The isAdmin middleware function checks for an active session with the admin role before allowing access to protected routes.

// server.js
const isAdmin = (req, res, next) => {
  if (req.session.user && req.session.user.role === 'admin') next();
  else res.status(403).json({ message: 'Admin required' });
};

Sources: server.js:27-36, server.js:38-41

This sequence diagram shows the login and data fetching flow.

Database Seeding (seed.js)

The seed.js script is a utility for populating the MongoDB database with an initial set of data. It connects to the database, defines a hardcoded array of model objects, and inserts them into the models collection.

The script is designed to be run from the command line. After successfully seeding the data, it prints a confirmation message and exits.

Sources: seed.js

Seeding Process

The flow of the seeding script is straightforward.

The data for each model is structured to match the Mongoose schema, including fields like id, name, profile, pricing, and dosAndDonts.

Sources: seed.js:4-61, APP/models/model.model.js:3-14

Python CLI Tool (model_database.py)

The repository contains a Python script, model_database.py, that provides a command-line interface (CLI) for managing a local database of models stored in a models.json file. This script appears to be a separate utility and does not interact with the Node.js server or the MongoDB database.

Sources: model_database.py

ModelDatabase Class

The script's functionality is encapsulated within the ModelDatabase class.

This class diagram shows the structure of the ModelDatabase class.

Functionality

• Data Persistence: The class loads data from models.json upon instantiation and saves data back to the file whenever a change is made (add, remove) or when the interactive session quits.
• Interactive Mode: The interactive_mode() method provides a simple REPL (Read-Eval-Print Loop) where the user can enter commands like add, remove, view, list, and quit to manage the models.
• Initial Data: The script includes a if __name__ == "__main__": block that initializes the database and adds a default "ROXIE SINNER" model if it doesn't already exist, before starting the interactive mode.

Sources: model_database.py:8-100, model_database.py:103-206

Data Schema (model.model.js)

The data structure for a "Model" is defined by a Mongoose schema. This schema enforces the types and required fields for documents stored in the models collection in MongoDB.

Sources: APP/models/model.model.js

Schema Definition

Field	Type	Required	Default	Description
id	String	Yes	-	A unique identifier for the model.
name	String	Yes	-	The name of the model.
age	Number	No	-	The age of the model.
location	String	No	-	The location of the model.
profile	String	Yes	-	A detailed profile description.
pricing	String	Yes	-	Pricing information.
dosAndDonts	String	Yes	-	A list of allowed and disallowed activities.
extraTabs	Array	No	[]	An array for additional information tabs.
history	Array	No	[]	An array to log changes to the document.

Sources: APP/models/model.model.js:3-14

History Tracking

The schema includes a pre('save') hook that automatically records changes to a model. Before an existing document is saved, an entry is pushed to the history array containing a timestamp, the action (update), and a list of the modified fields. This provides a simple audit trail for model updates.

// APP/models/model.model.js
schema.pre('save', function(next) {
  if (this.isModified() && !this.isNew) {
    this.history.push({
      timestamp: new Date(),
      action: 'update',
      changes: this.modifiedPaths()
    });
  }
  next();
});

Sources: APP/models/model.model.js:19-28