Architecture

Open Register sits between the client (a Nextcloud app, a browser, or any HTTP caller) and one or more storage backends. The request flow is schema-first: every write goes through validation before it touches a database.

Request flow

Layers

1 · API layer

The API layer is generated from your schemas. REST routes follow the pattern /api/objects/{register}/{schema} and accept JSON. A parallel GraphQL endpoint at /api/graphql exposes the same data through a typed query language. Both use the same validator and the same storage adapter.

2 · Schema registry

The schema registry holds every JSON Schema definition the system knows about. Schemas have a version, a source (manual, Schema.org, GGM), and a status (draft, published, deprecated). Lookups are cached in APCu with a 5-minute TTL.

3 · Validator

The validator runs every inbound object against the corresponding schema before it reaches the storage layer. Validation errors return as a structured 422 response with a JSON-Pointer path to each failing property.

4 · Storage adapter

The storage adapter interface decouples the API from the backend. Implementations exist for Nextcloud's internal database, MySQL/MariaDB, PostgreSQL, and MongoDB. New adapters implement four methods: find(), save(), delete(), search().

Architecture decisions

Performance

Reads benchmark at roughly 1,200 req/s on a single-node Nextcloud instance backed by PostgreSQL, with schema validation in the path. Writes sit around 600 req/s because of the audit-log signing step. See Performance notes for the full benchmark methodology.