How hammadgul-dev/blogify works
1. High-level shape
- Blogify is a two-tier MERN application: a React/Vite frontend and an Express/Node backend, with MongoDB as the primary system of record.
- The frontend is split into public blogging pages and an authenticated admin dashboard; the backend is organized around REST routes, controllers, and Mongoose models.
2. Frontend application shell
- Frontend/src/main.jsx boots the app, wiring together routing and the Redux store.
- Routes.jsx is the main client-side route map, covering public pages like Home, Auth, BlogDetail, and NotFound, plus the admin area.
3. Public content surface
- The public UI is composed from reusable components such as Navbar, HeroSection, PostLists, PostCards, PostComment, and Footer.
- These components consume blog data and comments from the backend and present the read-only publishing experience to anonymous users or logged-in users.
4. Admin dashboard boundary
- Frontend/src/Admin is a separate UI subsystem for content management.
- It includes an AdminLayout with a Sidebar, and pages for Dashboard, AddBlog, EditBlogs, Comments, and TrashBin.
- This boundary is important: admin features are not just different screens, but a different operational mode for blog creation, moderation, publishing, and recovery.
5. Client state and server-state split
- Redux Toolkit is used for application state that affects the whole UI: theme, notifications, search, and post filters.
- TanStack Query is used for server state and caching, which fits the blog/comment/admin data retrieval patterns.
- helper/apiFetch.js centralizes HTTP access to the backend, so the frontend’s data flow is routed through a single API abstraction.
6. Backend API layer
- The backend is segmented by domain in Backend/routes and Backend/controllers.
- Separate route groups exist for auth, blog management, add-blog tooling, comments, and trash-bin operations.
- This separation maps cleanly to the main business domains: identity, content creation, content lifecycle, and moderation.
7. Authentication and identity
- config/passport.js indicates Google OAuth is handled with Passport.js, alongside JWT-based auth endpoints in userAuthController.
- middleware/authMiddleware.js protects privileged routes, so admin actions and verified access are enforced on the server, not only in the UI.
- The auth flow supports both local JWT login/signup and Google sign-in, with token verification exposed to the frontend.
8. Blog content lifecycle
- Blog content is managed as an editable resource with create, update, publish/unpublish, soft delete, restore, and permanent delete actions.
- The presence of trashBinController and related routes shows that deletion is intentionally non-destructive until final removal.
- This creates a clear lifecycle boundary: active posts, trashed posts, and permanently removed records.
9. Comments and moderation
- Comments are a separate backend domain, not embedded in the blog model flow alone.
- The API supports adding comments, fetching comments by blog, deleting comments, and approving all comments for moderation workflows.
- That implies comments can be treated as user-generated content that may require admin review before appearing publicly.
10. Media and AI integrations
- middleware/upload.js and the README point to file upload handling through Multer and Cloudinary, which makes blog images an external storage concern rather than local filesystem state.
- The add-blog routes expose AI-assisted generation endpoints for descriptions and thumbnails, with Groq and an image-generation service called out in the README.
- These integrations sit on the backend side of the boundary so the frontend only triggers generation/upload actions and receives results.
11. Persistence and domain models
- config/db.js establishes the MongoDB connection used by the Mongoose models in models/.
- The visible models include user auth and blog-related records, suggesting the core persisted entities are users, blogs, and likely embedded or associated comment data.
- Data ownership is centralized in MongoDB, while Cloudinary owns uploaded media assets.
12. Deployment and routing concerns
- Both frontend and backend have Vercel configs, indicating the app is deployed as separate services rather than a single monolith.
- The frontend vercel.json likely supports SPA route fallback so direct visits to client routes work correctly.
- The backend vercel.json indicates the API is also packaged for serverless-style deployment.
13. Architecture diagram guidance
- A useful diagram would show the React frontend on the left, split into public UI and admin UI, both calling a shared API helper.
- In the middle, show the Express API with distinct route groups for auth, blogs, add-blog AI/upload, comments, and trash.
- On the right, show MongoDB as the primary datastore, Cloudinary as media storage, and external auth/AI services for Google OAuth and content generation.
Main entry points: apiFetch.js API helper · addBlogController.js Add-blog API · Routes.jsx Routes · userAuthController.js Auth API
Components 26
Frontend
React/Vite client with public blog UI and admin dashboard
- App boot · Starts the client app and wires store plus routing
Frontend/src/main.jsx - Routes · Main route map for public pages and admin area
Frontend/src/Routes.jsx - Public UI · Homepage, post detail, and shared reading components
Frontend/src/Pages/Home.jsx - Admin UI · Dashboard and management screens for blogs, comments, and trash
Frontend/src/Admin/Pages/Dashboard.jsx - UI state · Theme, notifications, search, and post filters
Frontend/src/Redux/Store.jsx - API helper · Shared frontend HTTP abstraction for backend requests
Frontend/src/helper/apiFetch.js
Backend
Express API, auth, content lifecycle, and moderation
- Auth API · Login, signup, and Google auth handling
Backend/controllers/userAuthController.js - Blog API · CRUD and publish flow for blog content
Backend/controllers/blogController.js - Add-blog API · Admin create flow, uploads, and AI-assisted generation
Backend/controllers/addBlogController.js - Comments API · Comment creation, lookup, deletion, and approval
Backend/controllers/commentsController.js - Trash API · Soft delete, restore, and permanent removal
Backend/controllers/trashBinController.js - Auth routes · REST endpoints for authentication and identity
Backend/routes/userAuthRoutes.js - Blog routes · REST endpoints for reading and managing posts
Backend/routes/blogControllerRoutes.js - Add-blog routes · Admin creation, upload, and AI generation endpoints
Backend/routes/addBlogRoutes.js - Comment routes · Endpoints for blog comments and moderation actions
Backend/routes/commentsRoutes.js - Trash routes · Endpoints for trashed content and recovery flows
Backend/routes/trashBinRoutes.js - Auth guard · Protects privileged server routes
Backend/middleware/authMiddleware.js - Upload middleware · Handles blog image upload processing
Backend/middleware/upload.js - Mongo config · Connects the API to MongoDB
Backend/config/db.js - Passport config · Configures Google OAuth strategy
Backend/config/passport.js - Users · Persisted user/auth records
Backend/models/userAuthModel.js - Blogs · Persisted blog records used by the content lifecycle
Backend/models/addBlogModel.js
External services
Datastore and third-party integrations
- MongoDB · Primary system of record
- Cloudinary · Stores uploaded blog images
- Google OAuth · External sign-in provider
- AI services · External text and image generation backends
Connections 29
- App boot → Routes: boots · Client entry initializes route handling
- App boot → UI state: provides · App-wide Redux state is wired at startup
- Routes → Public UI: public pages · Routes map to reader-facing screens
- Routes → Admin UI: admin area · Routes also mount the management workspace
- Public UI → API helper: reads data · Public pages load blogs and comments through the shared API helper
- Admin UI → API helper: mutates data · Admin screens perform content operations through the shared API helper
- UI state → Public UI: filters UI · Theme, search, and notification state affects the public experience
- API helper → Auth routes: calls · Frontend auth and identity requests go through the API layer
- API helper → Blog routes: calls · Frontend blog reads and updates go through the API layer
- API helper → Comment routes: calls · Comment operations go through the API layer
- API helper → Add-blog routes: calls · Admin create and generation actions go through the API layer
- API helper → Trash routes: calls · Trash and recovery actions go through the API layer
- Auth routes → Auth API: dispatches · Auth endpoints are handled by the auth controller
- Blog routes → Blog API: dispatches · Blog endpoints are handled by the blog controller
- Add-blog routes → Add-blog API: dispatches · Add-blog endpoints are handled by the creation controller
- Comment routes → Comments API: dispatches · Comment endpoints are handled by the comments controller
- Trash routes → Trash API: dispatches · Trash endpoints are handled by the lifecycle controller
- Auth API → Auth guard: protected by · Privileged auth-related actions are guarded where needed
- Add-blog API → Auth guard: protected by · Admin-only content creation is guarded server-side
- Blog API → Blogs: persists · Blog operations read and write blog records
- Comments API → Blogs: associates · Comment actions are tied to blog records
- Auth API → Users: persists · User identities are stored in the user model
- Blogs → Mongo config: uses · Blog data is stored through the configured database connection
- Users → Mongo config: uses · User data is stored through the configured database connection
- Mongo config → MongoDB: connects to · MongoDB is the primary datastore
- Upload middleware → Cloudinary: uploads to · Image handling sends media to Cloudinary
- Add-blog API → Upload middleware: uploads · Create flow uses upload middleware for images
- Passport config → Google OAuth: authenticates with · OAuth strategy delegates sign-in to Google
- Add-blog API → AI services: generates with · AI-assisted descriptions and thumbnails rely on external services