Resource lifecycle · Docs

Nimbly uses .meta event declarations for resource lifecycle side effects. A resource can declare what should happen after a record is created, updated, or deleted:

{
  "events": {
    "create": ["job:application-email-created"],
    "update": ["application-updated"],
    "delete": ["application-deleted"]
  }
}

Event payloads are intentionally small:

[
    'action' => 'create',
    'resource' => 'membership-applications',
    'uuid' => 'record-uuid',
    'data' => $record_data, // available for create/update/delete when already loaded
]

Plain event names are dispatched to module libraries by convention:

ext/modules/member/lib/application-updated.php
function application_updated($event) {}

Entries prefixed with job: enqueue a .jobs record instead of running work inline:

"events": {
  "create": ["job:application-email-created"]
}

Core setup creates the .jobs resource. job_enqueue() also creates it lazily if an older install does not have it yet.

Run queued jobs from CLI:

php core/cli/nimbly.php jobs:run

By default, jobs:run processes one eligible job. Pass an explicit limit only for catch-up runs:

php core/cli/nimbly.php jobs:run 25

Job handlers are module-discovered by convention:

ext/modules/member/lib/application-email-created.php
function application_email_created_job($job) {}

The queue stores intent and payload, not shell commands. Handlers may send email, call APIs, or perform other side effects.