0% found this document useful (0 votes)
3 views15 pages

Worksphere Project

The WorkSphere project features a fully developed backend using Express.js and MongoDB, while the frontend is in a mixed state with both an active Vite + React Router app and an in-progress Next-style migration. The backend is structured with clear routes, controllers, models, and middleware, but the frontend currently utilizes mocked API responses, preventing full integration. Overall, the backend is ready for production, while the frontend requires further development to connect with the backend effectively.

Uploaded by

Darshan Hn
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views15 pages

Worksphere Project

The WorkSphere project features a fully developed backend using Express.js and MongoDB, while the frontend is in a mixed state with both an active Vite + React Router app and an in-progress Next-style migration. The backend is structured with clear routes, controllers, models, and middleware, but the frontend currently utilizes mocked API responses, preventing full integration. Overall, the backend is ready for production, while the frontend requires further development to connect with the backend effectively.

Uploaded by

Darshan Hn
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

WORKSPHERE PROJECT - BRIEF EXPLANATION

1. PROJECT OVERVIEW

This project currently has:

- A real backend built with [Link] and MongoDB

- A frontend folder that contains both:

- an active Vite + React Router app

- a newer Next-style app structure that looks like an in-progress migration

So the backend architecture is clear and real, but the frontend has mixed structures.

2. MAIN BACKEND LOCATION

Backend files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend

Main backend entry file:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\[Link]

This file:

- starts the Express server

- connects MongoDB

- enables CORS

- enables JSON parsing

- mounts all API routes


- adds error handling middleware

- starts [Link]

3. MAIN FRONTEND LOCATION

Frontend files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend

Main frontend entry file:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\[Link]

This file mounts React and renders:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\app\[Link]

That means the active frontend currently runs through:

- Vite

- React

- BrowserRouter

- pages/ and services/ based structure

Important note:

The frontend folder also contains Next-style files like:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\app\[Link]
But under the current [Link], the app runs with Vite, not [Link].

So those Next-style files are not the main active entry path right now.

4. WHERE FRONTEND AND BACKEND CONNECT

Backend runs on:

[Link]

Database connection is configured in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\.env

Important values there:

- PORT=5000

- MONGO_URI=...

- JWT_SECRET=...

The MongoDB connection code is placed in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\config\[Link]

5. WHERE THE FRONTEND API URL IS PLACED

In a fully connected setup, the frontend should call backend APIs using a base URL like:

[Link]
In this project, the current API/helper file is:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\services\[Link]

But this file is currently using mock responses, not real backend fetch/axios calls.

So right now:

- backend is real

- frontend API file is mostly mocked

- active frontend is not fully connected to backend yet

This is why the project feels split between demo flow and real backend flow.

6. BACKEND FLOW

The normal backend request flow is:

Frontend -> Route -> Middleware -> Controller -> Model -> MongoDB -> Response

Detailed flow:

1. A request comes to Express server

2. [Link] receives it

3. Route file decides which controller to call

4. Middleware checks auth/role/errors if needed

5. Controller performs business logic

6. Controller uses Mongoose model to read/write MongoDB

7. Response is sent back as JSON


7. ROUTES

Route files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\routes

Examples:

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

Route export file:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\routes\[Link]

Purpose of routes:

- define API endpoint paths

- map each endpoint to the correct controller function

- keep URL structure organized feature-wise

Example:

/api/auth/login -> [Link] -> [Link]


8. CONTROLLERS

Controller files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\controllers

Examples:

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

Purpose of controllers:

- contain actual business logic

- validate request data

- call models

- prepare response JSON

Example:

In [Link], login:

- takes email and password

- finds user in database

- checks password
- creates JWT token

- sends user + token back

9. MODELS

Model files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\models

Examples:

- [Link]

- [Link]

- [Link]

- [Link]

- [Link]

Purpose of models:

- define MongoDB schema using Mongoose

- validate allowed fields

- define default values

- define hooks and methods

Example:

[Link] handles:

- name

- email
- password

- role

- skills

- experience

- assignedTechLead

- status

- profileCompletion

It also:

- hashes password before save

- checks role conditions

- exposes matchPassword() method

10. MIDDLEWARE

Middleware files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\middleware

Examples:

- [Link]

- [Link]

Purpose of middleware:

- run before controller or after controller errors

- handle repeated logic in one place


[Link] does:

- reads Bearer token

- verifies JWT

- loads logged-in user

- blocks unauthorized access

- checks active/inactive state

[Link] does:

- handles not found routes

- handles common backend errors in one place

11. UTILS

Utility files are in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\utils

Examples:

- [Link]

- [Link]

- [Link]

Purpose of utils:

- store reusable helper logic

- avoid duplicate code in controllers


Example uses:

[Link]:

- creates JWT token

[Link]:

- reads uploaded CSV file

- converts rows into user objects

[Link]:

- compares skills for project/employee matching logic

12. DATABASE CONNECTION

Database connection starts from:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\[Link]

That file calls:

connectDB()

which is defined in:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\config\[Link]

[Link] uses:

[Link]([Link].MONGO_URI, ...)
So the database flow is:

.env -> [Link] -> mongoose -> MongoDB Atlas

13. LOGIN FLOW EXAMPLE

Login flow in this project:

1. Frontend sends login request

2. Backend route /api/auth/login receives it

3. [Link] forwards request to [Link]

4. [Link] checks:

- email exists

- password matches

- user is active

5. [Link] creates JWT token

6. token and user data are returned

7. For later protected routes, [Link] verifies the token

14. FRONTEND FLOW

Current active frontend flow:

[Link]

->

[Link]

->

React Router routes

->
pages/*

->

components/*

->

services/[Link] or context provider

The current app shell uses:

- BrowserRouter

- Routes / Route

- page components from frontend/pages

- shared state from frontend/services/[Link]

15. IMPORTANT CURRENT LIMITATION

This repo currently mixes two frontend approaches:

1. Active Vite + React Router app

2. Inactive or partially migrated Next-style app structure

Also, the active API file is mocked, so the frontend is not fully talking to the real backend.

So if someone asks:

"How frontend and backend are connected?"

The correct answer is:

- Backend is fully structured and real

- Frontend has a connection layer file at frontend/services/[Link]


- But that file is currently using mock data instead of real backend URL calls

16. FINAL SIMPLE ARCHITECTURE

Intended full architecture:

Frontend UI

->

Frontend API/service layer

->

Backend route

->

Middleware

->

Controller

->

Model

->

MongoDB

->

Response back to frontend

Current practical situation:

- backend follows this architecture properly

- frontend is partly mock-based and partly in migration

17. MOST IMPORTANT FILES TO REMEMBER


Backend entry:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\[Link]

Backend DB config:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\config\[Link]

Backend env:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\.env

Backend routes:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\routes

Backend controllers:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\controllers

Backend models:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\models

Backend middleware:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\middleware

Backend utils:

C:\Users\DARSHAN\OneDrive\Documents\New project\backend_src\backend\utils

Frontend entry:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\[Link]

Frontend app shell:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\app\[Link]

Frontend API helper:


C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\services\[Link]

Frontend shared context:

C:\Users\DARSHAN\OneDrive\Documents\New project\frontend\services\learning-platform-
[Link]

18. SHORT CONCLUSION

This project is structured like a standard MERN-style application on the backend:

- Express for server

- Mongoose for models

- MongoDB for database

- JWT for auth

- middleware/controllers/routes/utils split properly

The frontend currently runs with Vite and React Router, but it still uses mock API responses in some
important places.

So the backend is already organized as a real production-style API, while the frontend is in a mixed
state between demo/mock flow and a newer app structure.

You might also like