thavasakthi/velodrive

Purpose and entry points

VeloDrive is a full-stack workspace-based file storage and management system. The backend HTTP server starts at backend/server.js; the browser SPA starts at frontend/src/main.jsx and composes routing/UI in frontend/src/App.jsx.

API and request boundary

Express route modules expose domain APIs for authentication, workspaces, folders, images/assets, trash, conversion, and administration:

• backend/routes/auth.js

• backend/routes/workspaces.js

• backend/routes/folders.js

• backend/routes/images.js

• backend/routes/trash.js

• backend/routes/convert.js

• backend/routes/admin.js

Cross-cutting middleware enforces login rate limiting, user authentication, workspace-scoped authorization, and admin access before route handlers reach data or storage operations:

• backend/middleware/loginLimiter.js

• backend/middleware/auth.js

• backend/middleware/workspaceAuth.js

• backend/middleware/admin.js

Persistent domain model

The backend models four central entities: users, workspaces, folders, and stored assets. Workspace membership/ownership is the key tenant boundary; folders organize assets, while trash routes likely implement soft-delete/recovery behavior.

• backend/models/User.js

• backend/models/Workspace.js

• backend/models/Folder.js

• backend/models/Asset.js

Quota and storage-accounting logic is centralized separately from route code:

• backend/utils/quotaHelper.js

• backend/scripts/recalcStorage.js

• backend/scripts/checkStorage.js

File lifecycle and storage operations

The primary operational flow is: authenticated client selects a workspace → folder/asset APIs mutate metadata and storage → quota checks constrain usage → frontend refreshes explorer state. Asset-specific endpoints and conversion form the file-processing boundary:

• backend/routes/images.js

• backend/routes/convert.js

• backend/models/Asset.js

Maintenance scripts indicate storage integrity, CDN URL repair, cleanup, and upload synchronization are operational concerns:

• backend/scripts/cleanupStorage.js

• backend/scripts/verify_storage.js

• backend/scripts/fix_cdn_urls.js

• backend/scripts/testUploadSync.js

The concrete storage provider is not identifiable from the supplied tree.

Frontend state and API integration

The React/Vite client uses centralized stores to separate session, selected workspace, file explorer, trash, confirmation dialog, and UI state. API transport and possible realtime/socket integration are isolated under src/api.

• frontend/src/api/axios.js

• frontend/src/api/socket.js

• frontend/src/stores/useAuthStore.js

• frontend/src/stores/useWorkspaceStore.js

• frontend/src/stores/useExplorerStore.js

• frontend/src/stores/useTrashStore.js

User-facing application stages

Authentication includes standard login and two-factor setup/login, followed by protected application views. The dashboard is the main explorer surface; workspace controls alter tenant context; trash and admin are separate operational surfaces.

• frontend/src/components/ProtectedRoute.jsx

• frontend/src/views/LoginView.jsx

• frontend/src/views/TwoFactorLogin.jsx

• frontend/src/views/TwoFactorSetup.jsx

• frontend/src/views/DashboardView.jsx

• frontend/src/views/TrashView.jsx

• frontend/src/views/AdminView.jsx

Runtime and deployment boundaries

Backend is a Node.js package/service defined by backend/package.json. Frontend is a Vite-built React application defined by frontend/package.json, with Vercel deployment configuration at frontend/vercel.json. The production frontend environment is supplied through frontend/.env.production; backend deployment and database/storage infrastructure are not described in the available README.