faiz4n/sonara

1. Overall shape

- Sonara is a two-tier full-stack app: a React/Vite frontend and a Node.js/Express backend.

- The frontend is a single-page application for discovery and artist workflows.

- The backend exposes a REST API for authentication, track management, album management, and file upload/storage.

2. Backend entry and layering

- Backend/server.js starts the service, while Backend/src/app.js assembles middleware and routes.

- The backend is organized into a typical layered structure:

- routes define HTTP endpoints,

- controllers implement request handling,

- models define MongoDB entities,

- middlewares enforce auth/guard logic,

- services encapsulate external integrations such as file storage,

- db holds the MongoDB connection setup.

- seed.js is a separate bootstrap path for populating initial data.

3. Backend domain model

- The main persisted entities are user, music, and album.

- This implies two core content types:

- individual tracks/music items with metadata and uploaded media,

- albums that organize tracks into collections.

- User identity is central because many endpoints are ownership-based, especially for artist actions like upload/delete/create.

4. Backend API boundaries

- Authentication lives under auth.routes.js and auth.controller.js.

- Music and album operations are handled under music.routes.js and music.controller.js.

- The API shape is centered around /api/auth and /api/music, with album endpoints nested under the music namespace.

- Some endpoints are public for discovery, while others are protected for the authenticated artist workflow.

5. Auth and access control

- auth.middleware.js is the main boundary between public access and protected artist actions.

- The readme indicates JWT-based authentication, so the backend likely issues tokens on login and validates them on protected requests.

- Ownership checks are important in the album/track management flows, especially for delete and creator-only operations.

6. File upload and external storage

- storage.service.js is a dedicated abstraction for media upload/storage.

- The stack uses Multer for incoming multipart file handling and ImageKit for persistent file hosting.

- This means media does not stay only on the API server; the backend acts as an ingestion and metadata/pointer manager, while actual asset delivery comes from the storage provider.

7. Backend data flow

- For upload actions, the flow is: client submits multipart form data → route/controller → auth/validation middleware if needed → Multer parses files → storage service sends assets to ImageKit → controller persists MongoDB metadata through models.

- For read actions, controllers query MongoDB models and return track/album documents to the frontend.

- For delete actions, controllers verify ownership, remove the MongoDB record, and likely coordinate cleanup of stored assets or references.

8. Frontend application shell

- The frontend is a Vite-built React application (main.jsx, App.jsx) with route-based navigation.

- src/services/api.js and the feature services (auth.service.js, music.service.js) form the network boundary to the backend.

- This separation keeps component code focused on UI/state, while service modules centralize API requests and payload shaping.

9. Frontend state and route protection

- authContext.jsx manages login/session state for the app.

- PlayerContext.jsx suggests a global playback state layer, even though the player feature is still in progress.

- ProtectedRoute.jsx and GuestRoute.jsx gate access to authenticated pages versus login/register flows, which mirrors the backend auth boundary.

10. Frontend feature areas

- pages/ contains the main screens: home, login, register, albums, album detail, profile, and ArtistStudio.

- components/forms/ hosts the main user interactions: login/register, track upload, and album creation.

- components/artist/, components/album/, and components/music/ separate artist management from public discovery and album detail rendering.

- components/layout/ provides the persistent shell such as sidebar and headers, while components/UI/ contains reusable primitives.

11. User journeys

- Guest flow: users land on discovery pages, can browse music/albums, and are routed to login/register for gated actions.

- Authenticated listener/artist flow: once signed in, the app can show profile data and allow access to protected resources.

- Artist studio flow: artists upload tracks, create albums from selected tracks, inspect their own catalog, and delete owned content.

- Album detail flow: album pages show header/metadata and track listings via modularized album components.

12. Responsive and deployment boundaries

- The frontend is styled with Tailwind and has explicit mobile-friendly layout components such as mobile sidebar variants.

- The frontend has a vercel.json, suggesting separate frontend deployment from the backend API.

- The backend and frontend therefore behave like independently deployable services, connected only through the API contract.

13. Key architectural takeaway

- The system is built around a clear split: React handles presentation, navigation, and client state; Express/MongoDB handle identity, catalog data, ownership checks, and media ingestion.

- The most important diagram edges are:

- browser/UI → frontend service layer → backend API,

- backend controllers → auth/middleware/models,

- backend storage service → ImageKit,

- backend models → MongoDB.