How Nexus PLM is put together

Nexus PLM is a small set of services behind one API, with clients that all speak to that API. Nothing bypasses it, and nothing but the data layer touches the database.

One API, many front doors

A central Engine service owns the data model and the rules. The web client, the CAD addins and anything else you connect all go through the same REST API, so behaviour cannot drift between them. A rule enforced once is enforced everywhere.

The services

Engine — the central API. Objects, revisions, links, lifecycle, workflow execution, permissions and audit.

Vault — content-addressed file storage. Files are stored by hash, so the same file arriving from three places occupies one slot and duplicates are impossible by construction.

Indexing — full-text search over attributes and document contents, including PDFs and Office files.

Translation — converts documents and drawings between formats as a background job.

Addin relay — a local service that brokers events between CAD applications and the platform, so a check-out in one client is reflected in the others.

Data layer

A repository and unit-of-work pattern over hand-written SQL rather than a heavyweight ORM, so the queries are readable and tunable. The database provider is a runtime choice: MariaDB for production, SQLite for local development, swapped by configuration rather than by rebuilding.

The type system

Object types, their attributes, lifecycle states and inheritance are held in a registry loaded at start-up and resolved in memory. Adding a type is configuration, not a schema migration and not a release.

Extension points

Workflows, indexers, translators and CAD addins are all plugins, discovered from configured paths at start-up. Their contracts live in separate packages, so extension code never references engine internals and cannot be broken by them.

Clients

A React web client for everyday work, and a Windows tray host that runs the CAD addins and relays their events. Both are consumers of the same API, with no privileged back door.

Security

Token-based authentication, group-based permissions and per-type visibility rules, all enforced server-side. Search results and relationship endpoints are scoped to what the caller is allowed to see, so an object you cannot read cannot be discovered through a link or a search result either.