Architecture Overview¶
Typical Data Flow¶
A typical command execution flow:
- User selects a device and command in the web interface
- View calls the command service to execute the command
- Service creates a connector via the factory
- Connector establishes connection to the device
- Command is executed and results are returned
- Service logs the execution and processes the results
- View renders the results to the user
This architecture ensures that each component has a single responsibility, making the code easier to maintain and extend.
Key Design Patterns¶
Factory Pattern¶
ConnectorFactory
creates platform-specific connectors:
Service Layer Pattern¶
Business logic isolated in dedicated services:
CommandExecutionService
- Command execution with retry logicDeviceService
- Device validation and infoRateLimitingService
- Command rate limiting
Platform-Based Architecture¶
Commands are tied to NetBox platforms, not device types:
Error Handling Strategy¶
Custom Exception Hierarchy¶
DeviceConnectionError
- Connection failuresCommandExecutionError
- Command execution issuesUnsupportedPlatformError
- Platform not supported
Error Recovery¶
- Automatic retry mechanisms in
CommandExecutionService
- Socket error handling in connection utilities
- Detailed error logging and user feedback
Tech Stack¶
- Scrapli/Scrapli-Community - Primary network device connections
- Netmiko - SSH fallback
- NetBox Platform Model - Command-platform associations
- Tabler CSS - UI framework (NetBox standard)
The error handling architecture provides:
- Hierarchical Exceptions: Custom exceptions for different error categories
- Contextual Error Messages: Errors include guidance based on the specific problem
- Graceful Degradation: Services handle errors and provide useful feedback
- Recovery Mechanisms: Automatic retry with exponential backoff for transient issues