System Architecture
The DeSIC Platform follows a conventional three-tier web architecture: a React single-page frontend, a Node.js/Express REST API, and a PostgreSQL relational database. The frontend never talks to the database directly — every read and write goes through an authenticated API call, which keeps authorization logic in one place.
Presentation tier
A React frontend that renders role-specific dashboards for innovators, mentors, and administrators.
Application tier
An Express.js REST API that owns all business logic, validation, and authorization decisions.
Data tier
A PostgreSQL database enforcing referential integrity through constraints, not just application-level checks.
Session layer
JSON Web Tokens carry identity and role between the frontend and API, validated on every protected request.
Request flow
- A user authenticates through the frontend, which posts credentials to the API's auth endpoint.
- The API verifies credentials against PostgreSQL, then issues a signed JWT encoding the user's identity and role.
- The frontend attaches that JWT to subsequent requests. Middleware on the API validates the token and enforces role-based access control (RBAC) before any handler runs.
- The handler executes business logic, reads or writes through PostgreSQL, and returns a JSON response.
- The frontend renders the result inside the dashboard appropriate to the user's role.
Why this shape
The three-tier split was chosen over a more tightly coupled design for a specific reason: it keeps the frontend replaceable. Because all business rules live in the API layer rather than in frontend components, the same backend could serve a future mobile client (see Roadmap) without duplicating validation or authorization logic.
Communication between tiers is stateless — the API does not hold session state in memory, which is what makes it possible to deploy the backend to a free-tier host that can spin instances up and down without losing user sessions (the JWT itself carries everything needed to re-authorize a request).
Where to go next
- Technology Stack for the specific frameworks and services behind each tier.
- Data Model for the entities that make up the PostgreSQL schema.
- Non-Functional Requirements for the performance and security targets this architecture was built to meet.