jihadul021/bookshare

1. System shape

- BookShare is a two-tier full-stack app: a React/Vite single-page frontend in client/ and an Express/MongoDB backend in server/.

- The frontend calls the backend over HTTP for most operations, while chat uses a Socket.io real-time channel.

- Data is persisted primarily in MongoDB through Mongoose models; uploaded book images are stored on the server under server/uploads.

2. Frontend application shell

- The client entry points are client/src/main.jsx and client/src/App.jsx, which likely establish global layout and route switching.

- Shared site chrome lives in components like Navbar, Footer, Banner, Categories, HowItWorks, and FloatingChat.

- Styling is a mix of CSS modules/files and Tailwind configuration, with Vite as the build tool.

3. Frontend feature areas

- The UI is organized by business domain rather than by generic widgets: authentication pages (LoginPage, RegisterPage, ForgotPasswordPage, VerifyEmailPage), catalog browsing (BookGrid, SearchFilters, SearchResults, ProductDetails), and user commerce flows (CartPage, WishlistPage, Checkout, PaymentPage, Congratulations).

- There are dedicated seller and admin surfaces: SellerProfile, SellerOrderManagement, MyBooksPage, plus admin screens for books, coupons, dashboard, orders, and users.

- Messaging has its own UI set: ChatWindow, Inbox, and the floating chat launcher.

4. Client-server boundary

- client/src/api.js and client/src/utils/apiUrl.js centralize backend communication and base URL handling.

- client/src/socket.js isolates the realtime client connection, separating chat transport from standard REST calls.

- getImageUrl.js suggests a small adapter layer for rendering uploaded media from backend paths.

5. Backend API layer

- The server is organized in classic Express MVC style: routes/ define endpoints, controllers/ contain business logic, models/ define MongoDB entities, and middleware/ handles cross-cutting concerns.

- Separate route modules exist for auth, books, cart, orders, wishlist, addresses, coupons, messages, payments, and admin functions.

- This structure implies domain-specific APIs rather than one monolithic controller.

6. Core data model boundaries

- The MongoDB models map directly to product domains: User, Book, Cart, Order, Wishlist, Address, Coupon, Conversation, and Message.

- Conversation and Message form the chat subsystem, distinct from commerce records.

- Orders, cart, and wishlist are separate collections, which suggests the app treats browse/save/buy states independently.

7. Authentication and authorization

- JWT-based auth is implemented through authController and authMiddleware.

- adminMiddleware enforces elevated access for the admin dashboard and management endpoints.

- The presence of VerifyEmailPage and ForgotPasswordPage plus emailService.js indicates account lifecycle flows beyond simple login/signup.

8. Commerce and fulfillment flow

- The buying path likely runs from catalog/product pages into cart, then checkout, payment, and order confirmation.

- orderController, cartController, addressController, and couponController split responsibilities for shipping, discounts, and order creation.

- Seller-side order handling is exposed separately from buyer-side order history, indicating distinct workflows for different roles.

9. Payments

- Stripe is integrated on the backend via paymentRoutes and surfaced in the frontend through PaymentPage.

- The README indicates support for both cash on delivery and card payments, so checkout branches into multiple payment methods.

- Stripe is test-mode friendly, which suggests payment intent handling is present but isolated from product data.

10. Real-time chat

- Chat uses Socket.io on the client and message-related backend controllers/routes/models.

- The README states messages are AES-encrypted before storage, so the message subsystem has a security boundary distinct from normal CRUD data.

- FloatingChat, ChatWindow, and Inbox imply both inline conversations and a persistent inbox view.

11. Admin and moderation boundary

- Admin pages and controllers manage users, books, orders, and coupons from a centralized dashboard.

- This is a separate operational surface from normal buyer/seller interactions, likely with stricter access checks and broader visibility into system data.

12. Media and infrastructure

- Book images are uploaded via middleware and stored under server/uploads, so the app handles file upload in addition to JSON APIs.

- Email delivery is handled by server/utils/emailService.js, likely for verification, password reset, and transactional notifications.

- The backend depends on environment variables for MongoDB, JWT, chat encryption, SMTP, client origin, and port configuration.

13. High-level data flow

- A typical request path is: React page/component -> API or Socket.io client -> Express route -> controller -> Mongoose model -> MongoDB.

- For user-facing actions like checkout or messaging, the backend may also involve Stripe, SMTP, or encryption utilities before persisting or responding.

- For architecture diagrams, the cleanest boundaries are: presentation layer, REST API layer, realtime chat layer, persistence layer, and external services (MongoDB, Stripe, SMTP).