construct metrics

construct-metrics

Import

import { constructMetrics } from '@dev-suite/decorators/construct-metrics'

Category

• class

Use Case

Measure constructor duration and success/failure for expensive object initialization.

Replaces

• Manual timing/reporting blocks in constructors
• One-off metrics wrappers per class

Example 1

Without decorator

class ModelCache {
  constructor() {
    const startedAt = performance.now();
    try {
      this.warmup();
      metrics.report({ name: 'ModelCache', success: true, durationMs: performance.now() - startedAt });
    } catch (error) {
      metrics.report({ name: 'ModelCache', success: false, durationMs: performance.now() - startedAt, error });
      throw error;
    }
  }

  private warmup() {}
}

With decorator

import { constructMetrics } from '@dev-suite/decorators/construct-metrics';

@constructMetrics({ reporter: metrics.report })
class ModelCache {
  constructor() {
    this.warmup();
  }

  private warmup() {}
}

Why better

• Metrics policy is centralized and reusable
• Constructor body is no longer polluted by telemetry boilerplate

Example 2

Without decorator

class FeatureIndex {
  constructor() {
    const start = Date.now();
    this.load();
    statsd.timing('feature_index.construct.ms', Date.now() - start);
  }

  private load() {}
}

With decorator

import { constructMetrics } from '@dev-suite/decorators/construct-metrics';

@constructMetrics({
  reporter: ({ className, durationMs, success }) => {
    statsd.timing(className + '.construct.ms', durationMs);
    statsd.increment(className + '.construct.' + (success ? 'ok' : 'fail'));
  },
})
class FeatureIndex {
  constructor() {
    this.load();
  }

  private load() {}
}

Why better

• One pattern supports both latency and outcome metrics
• Same metrics strategy can be applied to other classes quickly