133 lines
No EOL
3.7 KiB
Markdown
133 lines
No EOL
3.7 KiB
Markdown
# 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:
|
|
```typescript
|
|
const app = new ServiceApplication(
|
|
config,
|
|
{
|
|
serviceName: 'web-api',
|
|
// other options
|
|
}
|
|
);
|
|
|
|
// In container factory
|
|
const configWithService = {
|
|
...this.config,
|
|
service: { name: this.serviceConfig.serviceName }
|
|
};
|
|
```
|
|
|
|
After:
|
|
```typescript
|
|
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:
|
|
```typescript
|
|
const serviceName = config.service?.name || 'unknown';
|
|
// Had to handle different naming conventions
|
|
```
|
|
|
|
After:
|
|
```typescript
|
|
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
|
|
|
|
1. **Simplicity**: One configuration object with all necessary information
|
|
2. **Consistency**: Standardized service naming across the system
|
|
3. **Type Safety**: Unified schema provides better TypeScript support
|
|
4. **Backward Compatibility**: Old configuration formats still work
|
|
5. **Reduced Complexity**: No more manual config transformations
|
|
|
|
## Technical Details
|
|
|
|
### UnifiedAppConfig Schema
|
|
|
|
```typescript
|
|
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:
|
|
```typescript
|
|
'web-api': { db: 3, ... },
|
|
'webApi': { db: 3, ... }, // Alias for backward compatibility
|
|
```
|
|
|
|
## Future Improvements
|
|
|
|
1. Remove service name aliases after full migration
|
|
2. Deprecate old configuration formats
|
|
3. Add configuration validation at startup
|
|
4. Provide migration tooling for existing services |