Documentation
Getting Started
Data Grid
Modeling
Business Rules
Approvals
Users, Roles & Security
Administration
Integration & API
Installation
Migrating from MDS
Documentation/Architecture/System Architecture

System Architecture

System Architecture

Interactive diagram of the Primentra three-tier architecture. Hover any layer for details, simulate a request to trace the full data flow.

Frontend
React + Vite SPA
443 / 5173
React 18Vite 5History APIlocalStorage (demo)
HTTPS / TLS 1.2+
End-to-end encrypted
Reverse Proxy
IIS + ARR + URL Rewrite
TLS 1.2+
IIS 10ARR 3URL Rewrite 2.1HTTPS enforced
/api/* → localhost:3001
ARR reverse proxy
API Server
Express + Node.js 18
:3001
Express 4Node 18+mssql poolasyncHandler
mssql — TCP connection pool
Parameterized calls only
SQL Server
105 Stored Procedures · EAV Schema
:1433
SQL Server 2016+EAV modelFull-Text SearchFOR JSON PATH
Cross-cutting concerns
Audit Trail

Every create/update/delete/import writes an AuditLog row with user, action, entity, and timestamp. Append-only. Viewable in Admin panel.

Error Log

All server errors written simultaneously to errorlog.txt and the ErrorLog table. Queryable in Admin → Error Log.

RBAC Permissions

Users → Roles → per-entity permissions (None/Read/Write/Moderator). Checked by the API layer before every write operation.

Input Validation

All request bodies validated at the API layer before touching the database. Invalid input returns HTTP 400 immediately.

Architecture Documentation

Expand any section for full technical details.

Primentra is a Master Data Service built on a classic three-tier architecture: a React/Vite frontend running in the browser, an Express API server running in Node.js, and a SQL Server database storing all master data.

The architecture follows a strict separation of concerns. The frontend handles user interaction and state. The API handles routing, authentication, and input validation. The database handles all business logic, data integrity, and transactions. Nothing leaks into the wrong tier.

This design makes each tier independently testable, deployable, and replaceable. It also means that business rules are enforced at the database level — not in the browser or the API — making them impossible to bypass through direct API calls.

LayerTechnologyPortPrimary Responsibility
FrontendReact 18 + Vite 5443 (prod) / 5173 (dev)UI rendering, state management, API calls
Reverse ProxyIIS 10 + ARR + URL Rewrite443TLS termination, /api routing, SPA fallback
API ServerExpress 4 + Node.js 18+3001Input validation, stored procedure dispatch
DatabaseSQL Server 2016+1433Business logic, data integrity, auditing

Key architectural constraint: All business logic lives exclusively in SQL Server stored procedures. The Express API is a thin validation and routing layer — it contains zero raw SQL and no business rules. This makes the system easier to audit, test, and secure.

The diagram above shows the four layers a Primentra request passes through. Click any layer to expand its details.

What the diagram shows

The stack is read top to bottom. Each box is one layer, and the label between two boxes is the protocol that connects them.

  1. Frontend — a React + Vite single-page application in the browser, reached over port 443. It renders the data grid, the admin panel and the settings screens. It fetches every value through the REST API using the api.js helper. It stores no credentials and no secrets.
  2. Reverse proxy — IIS with Application Request Routing. It terminates TLS 1.2 or later, serves the static SPA files, and forwards /api/* to the API server.
  3. API server — Express on Node.js, listening on port 3001. It validates every input, then calls a stored procedure through the mssql driver. It contains no raw SQL.
  4. SQL Server — the database on port 1433. Every business rule, transaction and permission check lives in a stored procedure with the usp_ prefix.

The EAV store

Attributes are not columns. The database keeps one row per record in EntityRows and one row per attribute value in EntityValues. Adding an attribute to an entity inserts a definition row, not a schema change. This is why you can model new fields at run time without a migration.

Cross-cutting concerns

Four chips under the layer stack mark the concerns that apply at every level: the audit log, the error log, RBAC permissions and input validation.

What the diagram leaves out

Two features sit beside this path rather than inside it:

  • Integration views are SQL views generated per entity. External systems read master data straight from the database, without going through the API.
  • Staging tables live in a separate stg schema. A source system inserts rows there, and a batch process promotes them into the EAV tables.
The key principle: all business logic lives in stored procedures. The API is a validation and routing layer only. That keeps the logic centralized, auditable, and safe from SQL injection.

Ready to get started?

Start managing your master data with Primentra today.

View Pricing
System Architecture | Architecture | Docs | Primentra