Configuration Standardization

Overview

The Stock Bot system now uses a unified configuration approach that standardizes how services receive and use configuration. This eliminates the previous confusion between StockBotAppConfig and AppConfig, providing a single source of truth for all configuration needs.

Key Changes

1. Unified Configuration Schema

The new UnifiedAppConfig schema:

Provides both nested (backward compatible) and flat (DI-friendly) database configurations
Automatically standardizes service names to kebab-case
Handles field name mappings (e.g., ilpPort → influxPort)
Ensures all required fields are present for DI system

2. Service Name Standardization

All service names are now standardized to kebab-case:

dataIngestion → data-ingestion
dataPipeline → data-pipeline
webApi → web-api

This happens automatically in:

initializeStockConfig() when passing service name
ServiceApplication constructor
toUnifiedConfig() transformation

3. Single Configuration Object

Services now use a single configuration object (this.config) that contains:

All service-specific settings
Database configurations (both nested and flat)
Service metadata including standardized name
All settings required by the DI system

Migration Guide

For Service Implementations

Before:

const app = new ServiceApplication(
  config,
  {
    serviceName: 'web-api',
    // other options
  }
);

// In container factory
const configWithService = {
  ...this.config,
  service: { name: this.serviceConfig.serviceName }
};

After:

const app = new ServiceApplication(
  config,  // Config already has service.serviceName
  {
    serviceName: 'web-api',  // Still needed for logger
    // other options
  }
);

// In container factory
// No manual service name addition needed
this.container = await containerFactory(this.config);

For DI Container Usage

Before:

const serviceName = config.service?.name || 'unknown';
// Had to handle different naming conventions

After:

const serviceName = config.service?.serviceName || config.service?.name || 'unknown';
// Standardized kebab-case name is always available

For Configuration Files

The configuration structure remains the same, but the system now ensures:

Service names are standardized automatically
Database configs are available in both formats
All required fields are properly mapped

Benefits

Simplicity: One configuration object with all necessary information
Consistency: Standardized service naming across the system
Type Safety: Unified schema provides better TypeScript support
Backward Compatibility: Old configuration formats still work
Reduced Complexity: No more manual config transformations

Technical Details

UnifiedAppConfig Schema

export const unifiedAppSchema = baseAppSchema.extend({
  // Flat database configs for DI system
  redis: dragonflyConfigSchema.optional(),
  mongodb: mongodbConfigSchema.optional(),
  postgres: postgresConfigSchema.optional(),
  questdb: questdbConfigSchema.optional(),
}).transform((data) => {
  // Auto-standardize service name
  // Sync nested and flat configs
  // Handle field mappings
});

Service Registry

The SERVICE_REGISTRY now includes aliases for different naming conventions:

'web-api': { db: 3, ... },
'webApi': { db: 3, ... },    // Alias for backward compatibility

Future Improvements

Remove service name aliases after full migration
Deprecate old configuration formats
Add configuration validation at startup
Provide migration tooling for existing services

3.7 KiB Raw Blame History