1. Core concepts

Domain modeling

Designing tables, fields, and scripts to match real-world entities in a single business domain. A clear domain model keeps modules easy to read and extend.

Loose coupling

A design rule: expose the minimum set of fields so modules depend only on the interface, not on each other’s internals. The fewer fields you expose, the easier it is to update, reuse, and replace a module.

Module

A self-contained Ninox database that exposes selected data or logic through interfaces, so it can be reused, updated, and monetized without breaking connected systems.

Module interface

The standardized connection point that gives controlled access to a module’s data while preserving encapsulation.

Interface name

The single label that identifies an interface to both author and consumer; the consumer sees it as the module’s name. Because it is the API-level identifier for the interface itself, changing it creates a new interface and breaks existing connections until consumers update.

Separation of concerns

The practice of giving each module a single, well-defined responsibility and hiding everything else. This limits complexity and helps teams work in parallel.

2. Roles

End user

Operates the finished Ninox solution; may not know it contains modules.

Module author

Builds the provider database, exposes entities, versions the interface, and (eventually) publishes the module.

Module consumer

Installs the module, connects to its interface, and extends it inside their own Ninox app.

3. Databases and tables

Child database

A consumer database that connects to a provider’s interface. Ninox creates external tables—live replicas of the provider’s data.

External table

A table that Ninox automatically creates in a child database for every table the provider database exposes. While the interface is connected, the external table is a live replica of the provider’s data. If the interface is disconnected, the table remains in the child database with all data intact but stops syncing and behaves like a regular local table.

Table/field name

Caption visible only to the module author. It can be changed any time and is never shown to consumers.

Public table/field name

Editable label a consumer sees for a table or field. Renaming changes only the label; the underlying system ID remains the same.

Field type

One of three categories: data, layout, relationship. Only data fields can be exposed today. Relationship, formula, image/file, and dynamic choice fields are planned.

Provider database

Source database that owns the authoritative tables and fields and exposes them via an interface.

4. Interface actions

Expose (verb)

Make internal tables or fields publicly accessible through an interface, each with a unique public name. Expose defines what can be shared.

Provide (verb)

Supply live data or logic via an already exposed interface whenever consumers are connected. Provide delivers the shared data.

Publish (verb)

Package the module (including its interface) so it can be shared or imported into another workspace.

5. Data flow and permissions

Read access (interface)

Default permission for an exposed field or table. Child databases can view the provider’s data but cannot modify it. Every exposed element has at least Read access; Write access must be granted explicitly.

Write access (interface)

Lets a child database modify provider data through the interface. The provider always retains write access; this setting only grants it to children.