Metadata architecture

In TechAppForce an application is data. Entity definitions, fields, saved queries, screens, scripts and menus live in the metadata store; lifecycles, approval processes, triggers, workflows, notifications and reports are platform records written through the same data engine as business data.

How a definition becomes behaviour

• The data engine loads the entity for each request and derives columns, lookups, child records, custom fields, lifecycle and approval behaviour from its fields and flags.
• The runtime loads a screen's Form.io definition, already trimmed for the user's permissions, and renders it with the platform's components.
• Hooks and extensions are fetched by entity and phase, compiled (C# on the server, TypeScript in the browser) and cached.
• The DDL engine turns a table definition into PostgreSQL or SQL Server statements.

Versions

Metadata is written to main tables and copied into version tables that the runtime reads. Development reads the unversioned definitions; QA and Production read the release version their environment is pinned to. See Releases.

Record information

Every record has a record-information row with its tenant, app, environment, owner, audit fields, soft-delete flag, lifecycle status and search id. The data engine joins it on every query. This is how tenant scope, ownership and soft delete work without columns on each table.