The Problem

Salon owners that operate more than one branch often juggle separate booking sheets, customer records, and staff schedules. Switching between spreadsheets, email threads, and disparate point‑of‑sale tools leads to double‑bookings, lost revenue, and a fragmented client experience.

What This Does

The repository is a portfolio of six self‑contained projects that together implement a multi‑salon management suite:

  • Admin Panel – a React dashboard (Admin Panel/index.js) for owners to create services, view bookings, and run analytics.
  • Client Side – the public‑facing booking portal (Client Side/src/App.js) that customers use to browse services and schedule appointments.
  • Saloon Side – a staff‑oriented interface (Saloon Side/src/App.js) for checking daily calendars and marking attendance.
  • Email Server Backend – a Node/Express mailer that sends confirmation and reminder emails.
  • AI Skincare Recommendation – a small Flask/AWS‑Lambda service that runs a ML model (AI Sakincare Recommandation/mlmodel_flask/app.py).
  • Mobile Application – a thin native wrapper (4 source files) that points to the web UI.

All three React front‑ends share a common Firebase configuration (*/src/Firebase/firebase.js) and a Redux store (*/src/Redux/reduxStore). The back‑ends store bookings, customer profiles, and service catalogs in Firebase Firestore, while the email server pulls the same data to generate notifications.

How It Is Wired

Execution starts in each UI’s entry point (index.js → src/App.js). The app immediately imports its Firebase hub:

import firebase from './Firebase/firebase';

The hub (Client Side/src/Firebase/firebase.js and Saloon Side/src/Firebase/firebase.js) creates a single Firebase app instance and exports the Firestore reference. It is the most‑connected module (13 importers for the saloon side, 12 for the client side) and therefore carries the widest blast radius—any change to authentication or data paths ripples through every component that reads bookings.

After Firebase is initialized, the Redux store (src/Redux/reduxStore) is created and passed to <Provider>. The store’s reducers pull collections such as bookings, services, and customers from Firestore, then expose selectors used by UI components (e.g., components/Footer/Footer, components/Loader/loader). These UI components are leaf nodes with zero outgoing imports, keeping their impact localized.

When a user submits a booking, the flow is:

  1. UI component calls firebase.firestore().collection('bookings').add(payload).
  2. Firestore triggers a Cloud Function (not in this repo) that writes a document to the emailQueue collection.
  3. The Email Server Backend (Express) watches emailQueue and sends an email via the configured SMTP server.

The AI recommendation service runs independently. Its Flask entry point (AI Sakincare Recommandation/mlmodel_flask/app.py) loads a pickled model, exposes a /recommend endpoint, and is invoked from the client UI via a fetch call. The same logic is duplicated in the AWS Lambda variant (mlmodel_AWS_Lambda/app.py).

How To Use It

# Clone the whole portfolio
git clone https://github.com/moses-y/Multi-Beauty-Salon-Web-Application-In-ReactJS-Firebase.git
cd Multi-Beauty-Salon-Web-Application-In-ReactJS-Firebase

# ---------- React front‑ends ----------
# Each UI lives in its own folder; install dependencies and start a dev server.
cd Admin\ Panel
npm ci          # uses package-lock.json
npm start       # runs the dashboard on http://localhost:3000
# repeat for "Client Side" and "Saloon Side"

# ---------- Email server ----------
cd ../Email\ Server\ Backend
npm ci
npm start       # starts Express on the port defined in .env

# ---------- AI recommendation ----------
cd ../AI\ Sakincare\ Recommandation/mlmodel_flask
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python app.py   # runs Flask on localhost:5000

Configuration – each sub‑project expects a .env file with Firebase keys, SMTP credentials, and API secrets. The repository currently commits real values (Admin Panel/.env, Email Server Backend/.env); these must be replaced with placeholder examples (.env.example) and the real secrets rotated before any production run.

Real‑World Use

A chain of three salons installs the three React apps on separate sub‑domains (admin.example.com, book.example.com, staff.example.com). When a client books via book.example.com, the request writes to Firestore, the staff UI instantly reflects the new slot, and the Express mailer sends a confirmation. The owner monitors revenue dashboards in the Admin Panel, while the AI endpoint suggests skincare products based on uploaded photos.

Code Health & Issues

Measured findings (static analysis)

  • HIGH – Deep nesting in AI Sakincare Recommandation/src/Chatbot.js (9‑level indentation).
  • MEDIUM – Hub module */src/Firebase/firebase.js (13/12 importers).
  • HIGH – Duplicated code across mlmodel_AWS_Lambda/app.py, mlmodel_flask/app.py, and several test files.

Code‑health audit

  • CRITICAL – Rotate and remove committed credentials (Admin Panel/.env).
  • CRITICAL – Revoke exposed Google API key in the same file.
  • HIGH – Delete committed node_modules (23 478 files).
  • HIGH – Add a proper LICENSE (none at repo root).
  • HIGH – Add CI build gate for Admin Panel/vercel.json (no workflow).
  • HIGH – Replace wildcard CORS (*) in Flask app (mlmodel_flask/app.py).
  • HIGH – Disable Flask debug mode (app.run(debug=True)).
  • MEDIUM – Enable Dependabot (no update bot configured).
  • MEDIUM – Add pre‑commit secret scan (secrets currently tracked).

Additional hygiene notes: tests exist (≈1.9 k files) and GitHub Actions are present, but the repository lacks a Dockerfile and the license is missing.

The Bottom Line

The portfolio delivers a functional multi‑salon booking system built on React and Firebase, with a working email backend and a demo AI recommendation service. However, the codebase suffers from serious security hygiene lapses (committed secrets, exposed API keys) and maintenance concerns (deep nesting, duplicated logic, a massive committed node_modules). It is suitable for internal prototyping or as a reference implementation, but any production deployment must first remediate the critical health issues and streamline the duplicated modules.