abrartoha/educonnect

1. Repository shape

EduConnect is a monorepo with three user-facing runtimes and one shared backend: server/ for the API, client/ for the web SPA, and mobile/ for the Expo app. The web and mobile apps both consume the same backend API rather than talking directly to the database.

2. Backend as the system of record

The server/ workspace is the architectural center. It is a Node 20 + Express application using Prisma to persist data in PostgreSQL. All core business state lives here: users, profiles, posts, marketplace listings, leads/enquiries, campaigns, reviews, and admin operations.

3. Module boundaries on the server

The backend is split by feature area under server/src/modules/: auth, posts, directory, business, and admin. Each module has controllers, routes, and schemas, which makes the API surface explicit and keeps feature logic separated. The directory and business modules are especially important because they power the marketplace and enquiry workflows.

4. Data access and schema layer

Prisma is the persistence boundary. server/prisma/schema.prisma defines the domain model, while migrations show the evolution of features such as universities, meetings, messaging, and later simplification/removal of some of those models. This indicates the architecture is database-first with generated typed access through Prisma rather than ad hoc SQL.

5. Authentication and session model

Authentication is handled on the server with JWTs, cookies, CSRF protection, password hashing, and shared auth middleware. The repo uses both access/refresh token helpers and cookie utilities, so the system is designed around browser sessions rather than pure bearer-token APIs. Role-based access is a first-class concern because the app serves students, universities, agents, consultants, and admins.

6. Primary user flows

The most important product flows are feed/posts, marketplace browsing, role dashboards, and enquiry submission. Students can create and browse posts, explore directory listings for universities/agents/consultants, and contact a listing owner. Recipients can then review leads from their dashboards and update status through the backend.

7. Email-backed enquiries

A key architectural feature is the enquiry pipeline. When a student submits an enquiry, the server persists a Lead record and sends an email via nodemailer to the recipient, with the student as reply-to. In production this uses configured SMTP; in development it falls back to Ethereal preview URLs, so the email service is part of the core product flow rather than a peripheral notification layer.

8. Scheduled background jobs

server/src/jobs/cron.js introduces background processing for cleanup and lifecycle automation, including token cleanup and campaign auto-ending. This means some domain transitions happen asynchronously rather than only during request/response cycles.

9. Web client architecture

The client/ workspace is a React 19 + Vite SPA with React Router and Zustand. It is organized by page and component categories: landing pages, feed, marketplace, auth, dashboards, admin, and static/legal pages. The client is responsible for rendering the public marketing site plus authenticated role-specific UI.

10. Client-server integration

The web app has a dedicated API layer under client/src/api/ with endpoint definitions, mappers, and an API client, plus a useApiResource hook for data fetching. That separation suggests the UI consumes a normalized backend contract and then adapts raw API responses into view-friendly shapes. The store folder handles auth hydration and shared state across the SPA.

11. Mobile app parity

The mobile/ workspace mirrors much of the client’s domain structure: feed, marketplace, business, profile, admin, posts, and auth. It uses React Navigation with auth and main stacks, and stores auth tokens in AsyncStorage. This indicates the mobile app is a parallel client of the same backend, not a separate product with its own data model.

12. Shared domain surfaces across clients

Both clients expose the same core product concepts—feed/posts, directory listings, dashboards, and enquiries—but with different UI stacks. The mobile app has a slightly more compact feature set and native navigation, while the web app includes richer landing pages, admin screens, and an exploratory campus experience under client/src/pages/explore/.

13. Deployment and runtime boundaries

The repository includes containerization artifacts for both server and client, plus a Vercel config for the web app and a GitHub Actions deploy workflow. The practical runtime split is: Express API on port 5050, web SPA on 5173 in dev, and Expo Metro for mobile. PostgreSQL is an external infrastructure dependency required by the backend.

14. Cross-cutting concerns

Shared server middleware covers CORS, CSRF, security headers, rate limiting, validation, and centralized error handling. Those concerns define the trust boundary between clients and the API, and they are part of the architecture diagram because they sit in front of every feature module.

15. How to draw the diagram

A good architecture diagram should place PostgreSQL and email delivery as external dependencies behind the server, with the server in the center exposing role-aware API routes. The web SPA and mobile app should be shown as separate consumers of the same API, while background cron jobs attach to the server/database side for asynchronous maintenance.