Runtime Decorators

Runtime decorators describe operational policies that affect feature availability, tenant boundaries, scheduling, and resource consumption.

They express runtime intent as metadata. A cloud platform, scheduler, or other runtime consumer can interpret that metadata and apply the corresponding policy without coupling application code to a specific runtime implementation.

@tFeatureFlag#

Declares that an operation is gated by a feature flag.

import { tFeatureFlag } from '@axiljs/decorator'
 
@tFeatureFlag('new-checkout')
async checkout() {}
 
@tFeatureFlag('ai-search', { fallback: 'legacy-search' })
async search(query: string) {}

Feature flags allow runtime consumers to control whether functionality is available without changing the method's implementation.

@tExperiment#

Declares an A/B or multivariate experiment.

import { tExperiment } from '@axiljs/decorator'
 
@tExperiment({
  name: 'checkout-v2',
  variants: ['control', 'new']
})
async checkout() {}

The decorator describes the experiment and its variants so an external runtime or experimentation system can determine how execution should be assigned.

@tRollout#

Declares a progressive rollout percentage for a feature or operation.

import { tRollout } from '@axiljs/decorator'
 
@tRollout({ percentage: 10 })
async newFeature() {}

This allows a runtime consumer to gradually expose functionality rather than enabling it for every request at once.

@tTenant#

Declares that an operation requires a tenant context.

import { tTenant } from '@axiljs/decorator'
 
@tTenant()
async findUsers() {}
 
@tTenant({ strategy: 'subdomain' })
async getTenantData() {}

The tenant context can be resolved according to the strategy understood by the runtime consumer.

@tTenantBoundary#

Declares a tenant isolation boundary for an operation.

import { tTenantBoundary } from '@axiljs/decorator'
 
@tTenantBoundary('strict')
async updateUser() {}

Boundary levels#

This makes the intended tenant boundary explicit at the operation level.

@tCrossTenant#

Explicitly declares that an operation is authorized to access data across tenant boundaries.

Because cross-tenant operations are sensitive, they can be composed with audit semantics.

import { tCrossTenant, tAudit } from '@axiljs/decorator'
 
@tCrossTenant({ reason: 'platform-admin' })
@tAudit({ action: 'cross-tenant.inspect' })
async inspectTenant(tenantId: string) {}

The reason documents why cross-tenant access is permitted, while tAudit provides an explicit audit requirement for the operation.

@tSchedule#

Declares that a method should run according to a cron schedule or interval.

import { tSchedule } from '@axiljs/decorator'
 
@tSchedule('0 */5 * * *')
async syncProducts() {}
 
@tSchedule({
  cron: '0 0 * * *',
  timezone: 'Asia/Karachi',
  overlap: 'skip'
})
async dailyCleanup() {}

Scheduling semantics remain separate from the scheduler implementation. A runtime scheduler can consume the metadata and determine when the operation should execute.

@tQuota#

Declares a tenant resource quota that an operation consumes.

import { tQuota } from '@axiljs/decorator'
 
@tQuota({
  resource: 'api_calls',
  amount: 1
})
async makeApiCall() {}
 
@tQuota({
  resource: 'ai.tokens',
  amount: 1000
})
async generateSummary() {}

Quotas can represent API calls, AI tokens, or other runtime-managed resources.

@tResource#

Declares resource requirements for an operation.

import { tResource } from '@axiljs/decorator'
 
@tResource({
  cpu: '500m',
  memory: '256Mi'
})
async generateReport() {}

A runtime scheduler can use these requirements when deciding where and how the operation should execute.

@tInterval#

Declares a recurring execution interval.

import { tInterval } from '@axiljs/decorator'
 
@tInterval(30_000)
async healthCheck() {}

The value represents the requested interval in milliseconds.

@tDelay#

Declares a delay before execution.

import { tDelay } from '@axiljs/decorator'
 
@tDelay(5000)
async warmUpCache() {}

The delay is expressed in milliseconds.

@tRunAt#

Declares a specific execution time.

import { tRunAt } from '@axiljs/decorator'
 
@tRunAt('2025-12-31T23:59:59Z')
async newYearTask() {}

The timestamp is declared as metadata so a scheduling consumer can determine when the operation should run.

Combining Runtime Semantics#

Runtime decorators can be composed when an operation has multiple independent runtime requirements.

For example, a scheduled operation can also consume a tenant quota:

import {
  tSchedule,
  tQuota
} from '@axiljs/decorator'
 
@tSchedule('0 * * * *')
@tQuota({
  resource: 'api_calls',
  amount: 1
})
async syncTenantData() {}

Each decorator describes a separate concern. A scheduler can consume the scheduling metadata, while a quota system can consume the resource constraint.

Semantic Consumer Model#

AxilJS decorators do not need to own the runtime implementation.

The application declares intent:

@tFeatureFlag('new-checkout')
@tRollout({ percentage: 10 })
@tQuota({ resource: 'api_calls', amount: 1 })
async checkout() {}

Independent consumers can interpret these declarations:

• A feature-flag system evaluates tFeatureFlag.
• A rollout system evaluates tRollout.
• A quota system evaluates tQuota.
• A scheduler consumes tSchedule, tInterval, tDelay, or tRunAt.
• A tenant-aware runtime evaluates tTenant, tTenantBoundary, and tCrossTenant.

This separation keeps runtime semantics explicit while avoiding unnecessary coupling between application code and a particular infrastructure implementation.

Reference#

Runtime decorators turn operational requirements into explicit, machine-readable semantics. The application describes what an operation requires; runtime infrastructure can decide how those requirements are enforced.