How sabbirkhanoni/3d-web-application works
1. Overall shape
- This is a two-part full-stack app: a React/Vite frontend and an Express/MongoDB backend.
- The frontend handles the 3D editing experience and user-facing flows; the backend owns authentication, scene persistence, and premium subscription/payment state.
2. Frontend boundary
- frontend/src is organized around pages, layouts, contexts, and reusable components.
- Route-level pages cover landing, auth, password reset, scene view, and payment result states.
- AuthContext and SceneContext are the main client-side state boundaries: auth state drives access control, while scene state drives the 3D editor and sidebar controls.
3. 3D scene subsystem
- The core product experience lives in frontend/src/components/scene/SceneRoom.jsx.
- It uses the GLB assets in frontend/public/models and likely Three.js helpers to render a room, add furniture, and manipulate object positions.
- Supporting UI in frontend/src/components/dashboard/* manages selected object details, object lists, and add-object dialogs, which form the editor’s control surface around the canvas.
4. Scene data flow
- The scene editor maintains a list of objects with IDs, model types, and positions.
- User actions in the 3D canvas update the scene state in the frontend, then the scene can be saved to the backend.
- On load, the app restores the saved scene for the authenticated user, so the persisted scene is the source of truth across sessions.
5. Authentication subsystem
- Auth is session-based, not token-based: the backend uses express-session and HTTP-only cookies.
- backend/controllers/auth.controller.js, backend/services/auth.service.js, and backend/routes/auth.route.js separate HTTP handling, business logic, and routing.
- The frontend uses protected routes via frontend/src/layouts/ProtectRoute.jsx and auth state from AuthContext to gate access to the dashboard and scene editor.
6. Password reset and email flow
- Password recovery is OTP-based.
- The backend generates and stores a temporary OTP on the user record, sends it through Resend using backend/config/sendEmail.js and backend/utils/OTPSendingTemplate.js, then validates it before allowing password reset.
- This is a distinct backend flow from login/signup and is isolated in the auth controller/service layer.
7. Scene persistence subsystem
- Scenes are stored in MongoDB through backend/models/scene.model.js.
- The scene API in backend/controllers/scene.controller.js and backend/services/scene.service.js implements save/load/delete for a single user-owned scene.
- The model structure is intentionally simple: one scene per user, with an array of object descriptors rather than a full physics or scene graph engine persisted server-side.
8. Premium subscription subsystem
- Premium access is handled by SSLCommerz integration in backend/controllers/SSLCommerzPayment.controller.js and backend/services/SSLCommerzPayment.service.js.
- Payment state is tracked in backend/models/payment.model.js, while backend/validation/validationSSLCommerzPayment.js validates gateway payloads.
- The flow includes initiation, redirect to the gateway, success/failure/cancel callbacks, and IPN verification, with user subscription status updated in MongoDB.
9. Backend layering and boundaries
- The backend is split into:
- routes: request mapping,
- controllers: HTTP orchestration,
- services: business rules and external calls,
- models: MongoDB schemas,
- middleware: auth protection,
- config/utils/validation: DB connection, email sending, templates, and input checks.
- backend/middleware/isAuthenticated.js is the key enforcement point for protected APIs such as scene persistence and subscription initiation.
10. External dependencies and runtime
- MongoDB Atlas is the persistence layer for users, scenes, and payments.
- Resend is used for OTP email delivery.
- SSLCommerz is the payment provider for subscription upgrades.
- Deployment is set up for Vercel on both sides, with separate vercel.json files and environment-driven base URLs to connect the frontend to the backend.
11. Client-server interaction model
- The frontend talks to the backend over HTTP via Axios, with credentials included so the session cookie is sent automatically.
- Protected requests depend on that cookie; when the session is absent or invalid, the frontend route guard and backend middleware both enforce access boundaries.
- Payment redirects and callback pages are split between backend endpoints and frontend result pages, so the browser can move between the gateway, backend validation, and user-facing status screens.
12. Important architectural takeaway
- The architecture centers on a stateful authenticated user experience: login establishes a session, the scene editor reads/writes a per-user scene document, and subscription status changes user capabilities.
- The 3D editor, auth system, and payment system are separate subsystems, but they converge through the user record and session identity in MongoDB.
Main entry points: route.jsx Routes · auth.service.js Auth service · ProtectRoute.jsx Protected route · SceneRoom.jsx Scene room
Components 27
Frontend
React/Vite client for landing, auth, scene editing, and payment result views.
- App shell · Root client bootstrap and app wiring.
frontend/src/main.jsx - Routes · Top-level page and navigation composition.
frontend/src/routes/route.jsx - Auth state · Session-driven auth state and client-side access control.
frontend/src/context/AuthContext.jsx - Scene state · In-memory scene editor state shared across the UI.
frontend/src/context/SceneContext.jsx - Protected route · Route guard for authenticated areas.
frontend/src/layouts/ProtectRoute.jsx - Dashboard shell · Authenticated workspace frame around the editor.
frontend/src/layouts/Dashboard.jsx - Landing page · Public marketing and entry page.
frontend/src/pages/LandingPage.jsx - Login flow · Sign-in, signup, OTP, and password reset views.
frontend/src/pages/LoginPage.jsx - Scene page · Authenticated 3D scene editor entry point.
frontend/src/pages/SceneViewRoomPage.jsx - Payment states · Success, failure, and cancel screens after gateway redirects.
frontend/src/pages/PaymentSuccessPage.jsx - Scene room · Core 3D room and object manipulation experience.
frontend/src/components/scene/SceneRoom.jsx - Editor controls · Object lists, selection details, and add-object dialogs.
frontend/src/components/dashboard/SceneObjectsList.jsx - GLB assets · Furniture and room assets consumed by the scene editor.
frontend/public/models/home.glb
Backend
Express API for auth, scene persistence, and subscription payments.
- API server · Backend runtime and route mounting.
backend/index.js - Auth API · Login, signup, session, and password-reset orchestration.
backend/controllers/auth.controller.js - Scene API · Save, load, and delete the per-user scene document.
backend/controllers/scene.controller.js - Payment API · SSLCommerz initiation and callback handling.
backend/controllers/SSLCommerzPayment.controller.js - Auth service · Business logic for sessions, OTP, and user updates.
backend/services/auth.service.js - Scene service · Scene persistence rules and user-scene coordination.
backend/services/scene.service.js - Payment service · Gateway integration and subscription state changes.
backend/services/SSLCommerzPayment.service.js - Auth middleware · Protects private APIs using the session cookie.
backend/middleware/isAuthenticated.js - User model · User record with session, OTP, and subscription fields.
backend/models/user.model.js - Scene model · Single saved scene per user with object descriptors.
backend/models/scene.model.js - Payment model · Subscription and transaction state storage.
backend/models/payment.model.js
External data
Persistent and third-party systems used by the app.
- MongoDB · Persistent store for users, scenes, and payments.
- Resend email · OTP delivery for password recovery.
backend/config/sendEmail.js - SSLCommerz · External payment provider for premium subscription flows.
Connections 31
- App shell → Routes: boots · App renders the client route structure.
- Routes → Landing page: public · Landing page is available to unauthenticated users.
- Routes → Login flow: auth pages · Route set includes login, signup, OTP, and reset pages.
- Routes → Protected route: gates · Protected routes wrap private app areas.
- Protected route → Dashboard shell: allows · Authenticated users enter the dashboard shell.
- Protected route → Scene page: allows · Scene editor is behind auth protection.
- Dashboard shell → Scene room: hosts · Dashboard contains the main 3D editor surface.
- Scene page → Scene room: renders · Scene page mounts the room editor.
- Scene room → Scene state: reads/writes · Canvas interactions update shared scene state.
- Dashboard shell → Editor controls: controls · Sidebar controls manage selected objects and adding items.
- Scene room → GLB assets: uses · Room and furniture models are loaded into the scene.
- Auth state → Protected route: drives · Auth state determines access to private routes.
- Auth state → Auth API: sessions · Client authenticates against the backend session flow.
- Scene state → Scene API: syncs · Saved scene data is exchanged with the scene API.
- Payment states → Payment API: receives callbacks · Browser lands on payment result pages after gateway flow.
- API server → Auth API: routes · Server mounts auth endpoints.
- API server → Scene API: routes · Server mounts scene endpoints.
- API server → Payment API: routes · Server mounts payment endpoints.
- Auth API → Auth service: delegates · Controller pushes auth business logic into the service layer.
- Scene API → Scene service: delegates · Controller pushes scene operations into the service layer.
- Payment API → Payment service: delegates · Controller pushes gateway work into the service layer.
- Auth service → Auth middleware: protects · Auth-related protected endpoints rely on session checks.
- Auth service → User model: updates · User record holds session and OTP-related state.
- Scene service → Scene model: persists · Scene documents are stored per user.
- Payment service → Payment model: persists · Payment and subscription state are recorded.
- Auth middleware → User model: validates · Middleware resolves the active user from the session.
- User model → MongoDB: stored in · User data lives in MongoDB.
- Scene model → MongoDB: stored in · Scene documents live in MongoDB.
- Payment model → MongoDB: stored in · Payment documents live in MongoDB.
- Auth service → Resend email: sends OTP · Password reset OTPs are delivered by email.
- Payment service → SSLCommerz: charges via · Subscription checkout is handled by SSLCommerz.