QualityDocD is a production-ready, polyglot document quality management platform built for organizations that need structured approval workflows, immutable audit trails, and fast full-text search — all running as a coordinated set of Docker services. Rather than forcing every concern into one stack, QualityDocD assigns each responsibility to the technology best suited for it: a .NET MVC application for interactive document management, a Node.js REST API for programmatic multi-tenant access, a dedicated search microservice backed by MongoDB, and a PHP portal for read-only audit reporting. Together, these four services share three purpose-specific databases and communicate over a single Docker bridge network.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/juescoryisus/QualityDocD/llms.txt
Use this file to discover all available pages before exploring further.
Quickstart
Get the full stack running locally in under 5 minutes with Docker Compose.
Architecture
See how the four services and three databases connect.
Document Lifecycle
Learn the seven document states and how transitions work.
API Authentication
Authenticate against the Node.js REST API and obtain a JWT.
The Four Services
QualityDocD is not a monolith. Each service has a clear, bounded responsibility, and they interact over HTTP rather than sharing code or a database connection pool.| Service | Port | Technology | Role |
|---|---|---|---|
| .NET MVC App | 5001 | ASP.NET Core MVC + EF Core | Document CRUD, approval UI, cookie-based auth, YARP proxy |
| Node.js REST API | 5000 | Express 5 + TypeScript + drizzle-orm | JWT-authenticated REST API, multi-tenancy by company slug |
| Search Microservice | 3001 | Node.js + Mongoose | Indexes approved document metadata, serves full-text queries |
| PHP Portal | 8080 | PHP 8 + PDO | Read-only audit dashboard backed by PostgreSQL and the search service |
.NET MVC Application
The .NET application is the primary user interface. It handles document creation, editing, and the full approval workflow through a conventional server-rendered MVC UI. Authentication is cookie-based with an 8-hour sliding session. On startup, the application runs EF Core migrations against SQL Server and seeds the initial set of users if theUsers table is empty. It also embeds a YARP reverse proxy that transparently forwards /node-api/{path} requests to the Node.js API and /search/{path} requests to the search microservice, allowing all browser traffic to flow through a single origin.
Node.js REST API
The Node.js API exposes a JSON REST interface for programmatic document management. Every request is authenticated with a JWT issued byPOST /api/auth/login. Data is scoped to a company slug — every user, document, and search result belongs to a specific company — making the API ready for multi-tenant deployments. Access to features is further controlled by module flags (MODULE_1, MODULE_2, MODULE_3) that can be toggled per company. The API persists its data to PostgreSQL using drizzle-orm.
Search Microservice
The search microservice is a lightweight Node.js service that connects to MongoDB. When a document is approved in the .NET application, its metadata is pushed to this service, which writes a record into thedocument_metadata collection in the qualitydoc_meta database. The service exposes full-text search endpoints under /api/ and a health check at GET /health.
PHP Portal
The PHP portal is a read-only reporting dashboard. It reads audit entries from the PostgreSQLqualitydoc_audit database and calls the search microservice directly to display document metadata. The portal authenticates portal sessions by delegating login to the .NET API’s /api/auth/login endpoint and storing the resulting JWT in a PHP session.
The Three Databases
QualityDocD uses three databases, each chosen for a specific type of data.| Database | Version | Port | What It Stores |
|---|---|---|---|
| SQL Server | 2022 Express | 1433 | Documents, users, document approvals, workflow state |
| PostgreSQL | 16 | 5432 | Audit log entries (PHP portal), Node.js API relational data |
| MongoDB | 7 | 27017 | Document metadata collection for full-text search |
document_approvals table that tracks each workflow transition.
PostgreSQL serves two consumers: the Node.js API uses it (via drizzle-orm) for its own relational tables (companies, users, documents, document versions, search index), and the PHP portal queries the audit_entries table directly to render the audit dashboard.
MongoDB stores flexible document metadata in the qualitydoc_meta database. The document_metadata collection is populated by the search microservice whenever a document reaches the Approved state, enabling fast full-text queries without loading SQL Server.
Key Capabilities
Approval Workflows
Documents move through a defined lifecycle managed by the .NET application:Draft → UnderReview → Approved (or Rejected or PendingChanges for revision loops) → Obsolete. Every transition is recorded. Managers initiate reviews; Reviewers accept, reject, or request changes; Admins can override any state.
Role-Based Access Control
QualityDocD defines five roles in the .NET application, each with a distinct set of permissions across the document management UI:| Role | Description |
|---|---|
| Admin | Full access — user management, all documents, override any workflow state |
| Manager | Submit documents for review, approve or reject, view all department documents |
| Reviewer | Review assigned documents, accept or request changes |
| Editor | Create and edit documents, submit for review |
| Viewer | Read-only access to approved documents |
The Node.js REST API uses a separate role system:
VIEWER, COMMENTER, CONTRIBUTOR, OPERATOR, COMPANY_ADMIN, and SUPER_ADMIN. These roles are independent of the .NET application roles above and govern access to Node.js API endpoints and module flags.Full-Text Search
Approved document metadata is indexed in MongoDB. The search microservice accepts text queries and returns matching document records. The Node.js API also maintains a token-based search index in PostgreSQL as a secondary search path.Audit Logging
Every document state transition is written to both SQL Server (for the .NET app’s own history views) and PostgreSQL (for the PHP portal’s audit dashboard). This dual-write ensures that the reporting tier never depends on SQL Server availability.Multi-Tenancy
The Node.js API scopes all data to a company slug provided at login. A user logging in withcompanySlug: "acme" can only see documents, versions, and search results belonging to the acme company. Module-level flags provide additional per-company feature gating.