ashikurrafi/blog

1. Top-level split

- The repository is a classic two-tier app: a React client in client/ and a Node/Bun backend in server/.

- The client is a single-page application that talks to the server over a JSON API; the server owns persistence, authentication, authorization, and file uploads.

2. Frontend shell and navigation

- The client is organized around route-level page components under src/pages/.

- There are distinct UI zones: public (HomePage, SinglePostPage), auth (LoginPage, RegisterPage), dashboard (CreatePostPage, EditPostPage, MyPostsPage, ProfilePage), and admin (AdminPostsPage, AdminCategoriesPage, AdminUsersPage).

- Layout components in src/components/layout/ (PublicLayout, DashboardLayout, Navbar, Sidebar, Footer) indicate the app uses shared shells to separate public browsing from authenticated work areas.

3. Client-side state and API boundary

- Redux is the central client state mechanism, with slices for auth, blog, category, comment, and UI in src/redux/.

- src/api/apiClient.js is the main transport boundary for server calls, so data-fetching and mutations are centralized rather than scattered through pages.

- This suggests the client reads server state into Redux and uses the store to coordinate auth status, post lists, categories, comments, and UI concerns like dialogs/loading.

4. Frontend component structure

- src/components/ui/ contains reusable primitive widgets such as buttons, dialogs, tables, forms, tabs, alerts, and sheets, which are then composed by pages and layouts.

- This creates a three-layer client structure: page orchestration → layout shell → reusable UI primitives.

5. Backend application structure

- The server is organized in a standard route → controller → model flow.

- src/server.js and src/app.js are the entry points, while src/routes/index.js aggregates feature routes such as auth, blog, category, comment, user, and admin.

- This separation keeps HTTP wiring isolated from business logic.

6. Domain modules on the server

- Core business domains are represented by models in src/models/: user, blog, category, and comment.

- Controllers mirror those domains in src/controllers/, with separate handlers for authentication, blog content, categories, comments, users, and admin operations.

- The data model implies a blog platform with posts, categorization, user accounts, and threaded/attached comments.

7. Persistence and data access

- src/config/db.js handles database connection setup, and the presence of model files strongly suggests a MongoDB/Mongoose-style persistence layer.

- The server does not appear to expose direct database access to the client; all reads/writes are mediated through controllers and route handlers.

8. Authentication and authorization

- src/middleware/authMiddleware.js and isAdminMiddleware.js enforce access control at the route layer.

- This creates three trust levels:

- public readers,

- authenticated users who can manage their own profile/posts,

- admins who can manage users, categories, and posts globally.

- The dedicated auth and user routes indicate login/registration and account-related APIs are separate from content APIs.

9. Media upload and external storage

- src/middleware/multer.js, src/utils/dataUri.js, and src/utils/cloudinary.js show that post images or user avatars are uploaded through the backend and pushed to Cloudinary.

- The backend therefore acts as the upload gateway, converting multipart file input into a Cloudinary-hosted asset and storing the resulting metadata in the database.

10. Error and response conventions

- src/errors/apiError.js, apiResponse.js, and asyncHandler.js provide a shared HTTP error/response pattern.

- This indicates the API is standardized around consistent JSON responses and centralized async error handling, which simplifies client integration and server maintenance.

11. Content integrity and cascading behavior

- src/utils/cascadeDelete.js suggests the backend handles dependent-record cleanup when content is removed.

- That is important for a blog system where deleting a category, user, or post may require removing or reassigning related posts/comments.

12. Primary end-to-end flows

- Public browsing: client public pages fetch blog content and display single posts.

- Signup/login: auth pages call auth routes, update Redux auth state, and unlock protected layouts.

- Author workflow: dashboard pages create/edit/manage a user’s own posts and profile.

- Admin workflow: admin pages manage site-wide posts, categories, and users.

- Commenting: comment-related state and routes support post detail interactions.

13. Technology cues that matter for the diagram

- The client is built with React + Vite and uses Bun-managed dependencies (bun.lock).

- The server is also Bun-managed and likely runs as a Node-compatible HTTP API.

- The architecture is therefore a separated SPA frontend plus REST-style backend, with Cloudinary as the only clearly visible external service.