iftekhartamim595/gradbridge

1. GradBridge is a two-tier monolith: a Django backend API and a React/Vite frontend SPA. The backend is split into feature apps rather than microservices, and the frontend consumes those APIs plus a WebSocket chat channel.

2. The backend’s architectural root is backend/config, which wires Django settings, ASGI/WGI entrypoints, URL routing, static file serving, JWT auth, CORS, Channels, and production deployment behavior. Procfile, render.yaml, runtime.txt, and build.sh show it is intended for hosted deployment with Gunicorn and a managed runtime.

3. Identity and access control are concentrated in accounts. This app owns the custom user model, role/approval workflow, Google OAuth integration, serializers/views for auth endpoints, and permission logic. It is the foundation for role-based branching across the rest of the platform.

4. User-facing profile data lives in profiles, which models student and alumni profiles, certificates, visibility controls, and profile enrichment. Signals in this app indicate that profile creation/update side effects are automatic rather than manually triggered from the UI.

5. Discovery and matching are handled by search, projects, and community. search provides filtered alumni discovery, projects stores portfolio/work samples, and community appears to support broader social or feed-style interactions. These features depend heavily on profile visibility and user role.

6. Mentorship and job workflows are separate bounded areas. mentorship models mentorship requests and their lifecycle, while jobs owns job postings, recruiter-specific fields, applications, and related utilities. The README’s recruiter approval flow suggests accounts and jobs cooperate to enforce who can publish jobs.

7. Real-time communication is implemented with Django Channels in chat. The presence of consumers.py, middleware.py, and routing.py indicates WebSocket-based messaging, while REST endpoints still exist for conversation and message history. The frontend has a chat context and socket hook, so chat uses both HTTP for persistence and WebSockets for live delivery.

8. Notifications are a separate event-driven concern in notifications. The signals.py file suggests notifications are produced by model events across other apps, not only by explicit API calls. This makes notifications a cross-cutting subsystem rather than a standalone user action flow.

9. AI-powered resume analysis is isolated in ai_insights, with an openrouter.py integration and utilities for processing resume content. The frontend’s AIInsights and ResumeAnalysis pages likely upload a resume to this API, which then returns scoring, skill-gap analysis, and recommendations. ml_engine looks like a separate internal service layer for ML-related logic, but the primary external LLM integration is OpenRouter.

10. Email delivery and validation are centralized under utils, especially email_service.py and validators.py. This keeps outbound communication and shared input checks out of individual feature apps, which is important because chat, mentorship, account actions, and notifications all appear to trigger email side effects.

11. The frontend is a role-aware SPA organized around pages, reusable components, and React contexts. AuthContext, ChatContext, and ModalContext provide shared client-side state, while route guards like PrivateRoute and ApprovedRecruiterRoute enforce access rules before a screen is rendered.

12. API access on the frontend is centralized in src/api, with apiClient.js and ai.js acting as the main service layer. This means pages do not talk directly to the backend; they go through a common request layer that likely handles JWT attachment, error handling, and environment-based base URLs.

13. The user journeys are clearly role segmented in the page structure: student dashboards and profile views, alumni dashboards and search, recruiter hiring flows, admin pages, messages, community, jobs, mentorship, and resume analysis. That separation mirrors the backend app boundaries, which makes the diagram easier to draw as matching frontend modules to backend domains.

14. Overall data flow is: browser auths against accounts, receives JWTs, then uses REST APIs for profiles/search/jobs/mentorship/notifications/AI and WebSockets for chat. Cross-cutting events like profile updates, mentorship actions, and job/application changes can emit notifications and emails, while AI resume uploads go out to OpenRouter through the backend.