mehedi-bit/journey-with-quran

1. Overall shape

This is a two-tier application: a React + TypeScript SPA in frontend-v2/ and an Express + Node.js API in backend/, with MongoDB/Mongoose as the persistent store. The product mixes a community journaling/social layer with Quran study content.

2. Frontend boundary

The frontend is a Vite-based client app (main.tsx, App.tsx) organized as routed page components under src/components/pages. It is the primary user-facing boundary for authentication, profile management, posts, users, and Quran/tafsir/hadith browsing.

3. Frontend state model

Client state is centralized with small “atom” stores in src/atoms/ (authAtom, userAtom, postsAtom, feedAtom, currentPostAtom). That suggests the app shares auth/session state, current user data, and post/feed data across many pages without prop-drilling.

4. Frontend feature clusters

The UI is split into clear domains:

- components/auth for login/signup/logout/profile update

- components/post for creating, viewing, commenting, and post menus

- components/user and components/suggestedUser for profile/social interactions

- components/surah, components/tafsir, components/Hadith for Quran study content

- components/common for global layout and modals like navbar, sidebar, theme switcher, report popup, welcome modal

5. Frontend UI foundation

There is a reusable UI toolkit under src/components/ui/ and a theme provider. This implies a design-system style setup, likely with modal/dialog, tabs, sheet, dropdown, form, and input primitives reused across pages. The frontend also includes usePreviewImage, indicating image upload/preview UX for profile or post media.

6. Backend entry and routing

The backend is structured conventionally around server.js as the entrypoint, routes/ for HTTP endpoints, controllers/ for request logic, middlewares/ for auth protection, and models/ for Mongoose schemas. connectDB.js establishes the MongoDB connection before the API serves traffic.

7. Backend domain model

The visible database model boundary is small and focused: userModel.js and postModel.js. That means the backend’s persistent core is the social layer—accounts, profiles, follows, posts, comments/replies, and associated metadata—rather than Quran content storage.

8. Authentication and authorization

Auth is cookie/JWT-based. generateTokenAndSetCookie.js issues auth tokens, and protectRoute.js guards protected endpoints. So the request path is: client submits credentials or session-changing actions → backend validates → sets token cookie → protected controllers read the authenticated user context.

9. Social data flows

The README’s “atomic updates” and “auto propagation” show that profile changes and follow/unfollow actions are treated as cross-document operations. In architecture terms, this means a user update may cascade to many posts/comments, and follow relationships likely touch multiple user records or arrays, with MongoDB transactions used to keep those writes consistent.

10. Content and external-service considerations

The frontend contains dedicated Quran/tafsir/hadith views, but the backend tree does not show models/routes for those domains. That suggests those experiences are either client-side/static or sourced externally, while the backend remains centered on social journaling. Environment variables mention Cloudinary, so image upload/storage is part of the backend’s infrastructure boundary even though its integration code is not shown here.

11. Deployment/tooling boundary

The frontend has Vite, Tailwind, and a vercel.json, so it is likely deployed independently from the backend. The backend uses environment-based configuration (.env.example) and is designed for local development with separate frontend/backend servers.

12. Diagram takeaway

For an architecture diagram, model:

- a browser SPA with shared atom-based client state

- an Express API with auth, user, and post controllers

- a MongoDB/Mongoose persistence layer

- Cloudinary as an external media service

- a content browsing frontend for Quran/tafsir/hadith that sits alongside the community journaling features rather than inside the backend domain.