dcrouter/readme.plan.md

276 lines
10 KiB
Markdown
Raw Normal View History

2025-05-22 10:18:02 +00:00
# SMTP Client Refactoring Plan
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
## Problem Statement
2025-05-21 02:17:18 +00:00
2025-05-22 10:18:02 +00:00
Following the successful SMTP server refactoring, the SMTP client implementation in `classes.smtp.client.ts` has grown to be too large and complex, with over 1,421 lines of code. This monolithic structure makes it difficult to maintain, test, and extend. We need to refactor it into multiple smaller, focused files to improve maintainability and achieve consistency with the server architecture.
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
## Refactoring Goals
2025-05-21 02:17:18 +00:00
2025-05-22 10:18:02 +00:00
1. Improve code organization by splitting the SmtpClient class into multiple focused modules
2. Enhance testability by making components more isolated and easier to mock
2025-05-21 12:52:24 +00:00
3. Improve maintainability by reducing file sizes and complexity
2025-05-22 10:18:02 +00:00
4. Achieve architectural consistency with the refactored SMTP server structure
5. Preserve existing functionality and behavior while improving the architecture
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
## Proposed File Structure
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
```
mail/
└── delivery/
2025-05-22 10:18:02 +00:00
├── smtpclient/
2025-05-21 12:52:24 +00:00
│ ├── index.ts - Main export file
2025-05-22 10:18:02 +00:00
│ ├── interfaces.ts - All SMTP client interfaces
│ ├── constants.ts - Constants and error codes
│ ├── smtp-client.ts - Main client class (core functionality)
│ ├── connection-manager.ts - Connection pooling and lifecycle
│ ├── command-handler.ts - SMTP command sending and parsing
│ ├── auth-handler.ts - Authentication mechanisms
│ ├── tls-handler.ts - TLS and STARTTLS client functionality
│ ├── error-handler.ts - Error classification and recovery
│ ├── create-client.ts - Factory function for client creation
2025-05-21 12:52:24 +00:00
│ └── utils/
2025-05-22 10:18:02 +00:00
│ ├── validation.ts - Input validation utilities
│ ├── logging.ts - Client-side logging utilities
│ └── helpers.ts - Protocol helper functions
├── classes.smtp.client.ts - Legacy file (will be deprecated)
2025-05-21 12:52:24 +00:00
└── interfaces.ts - Main delivery interfaces
```
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
## Module Responsibilities
2025-05-21 02:17:18 +00:00
2025-05-22 10:18:02 +00:00
### 1. smtp-client.ts (150-200 lines)
- Core client initialization and lifecycle management
- Client configuration and options handling
- Connection coordination and delegation
- High-level send operations
2025-05-21 12:52:24 +00:00
- Delegates to other modules for specific functionality
2025-05-21 02:17:18 +00:00
2025-05-22 10:18:02 +00:00
### 2. connection-manager.ts (150-200 lines)
- Connection pooling and reuse
- Socket lifecycle management
- Connection timeout handling
- Connection health monitoring
- Connection error recovery
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
### 3. command-handler.ts (200-250 lines)
2025-05-22 10:18:02 +00:00
- SMTP command formatting and sending
- Server response parsing and validation
- Command pipeline management
- Response code interpretation
- Protocol state tracking
### 4. auth-handler.ts (150-200 lines)
- Authentication mechanism selection
- PLAIN, LOGIN, OAUTH2 implementation
- Credential management
- Authentication challenge handling
- Authentication error handling
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
### 5. tls-handler.ts (100-150 lines)
2025-05-22 10:18:02 +00:00
- TLS connection establishment
- STARTTLS client implementation
- Certificate validation
- Secure socket creation and management
- TLS error handling
### 6. error-handler.ts (150-200 lines)
- SMTP error code classification
- Error recovery strategies
- Retry logic implementation
- Error logging and reporting
- Connection failure handling
### 7. create-client.ts (50-100 lines)
- Factory function for client creation
- Dependency injection setup
- Configuration validation
- Component initialization
- Default option handling
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
### 8. interfaces.ts (100-150 lines)
2025-05-22 10:18:02 +00:00
- All client interface definitions
- Type aliases for client operations
- Error type definitions
- Configuration interfaces
- Result type definitions
2025-05-21 02:17:18 +00:00
2025-05-21 12:52:24 +00:00
## Implementation Strategy
2025-05-21 02:17:18 +00:00
2025-05-22 10:18:02 +00:00
### Phase 1: Initial Structure and Scaffolding (Days 1-2) ✅
1. ✅ Create the folder structure and empty files
- ✅ Create `mail/delivery/smtpclient` directory
- ✅ Create all module files with basic exports
- ✅ Set up barrel file (index.ts)
2. ✅ Move interfaces to the new interfaces.ts file
- ✅ Extract all interfaces from current client implementation
- ✅ Add proper documentation for client-specific interfaces
- ✅ Add any missing interface properties
3. ✅ Extract constants and enums to constants.ts
- ✅ Move all SMTP client constants and error codes
- ✅ Ensure proper typing and documentation
- ✅ Replace magic numbers with named constants
4. ✅ Set up the basic structure for each module
- ✅ Define basic class skeletons for each handler
- ✅ Set up dependency injection structure
- ✅ Document interfaces for each module
### Phase 2: Gradual Implementation Transfer (Days 3-7) ✅
1. ✅ Start with utility modules
- ✅ Implement validation.ts with input validation functions
- ✅ Create logging.ts with client-side logging utilities
- ✅ Build helpers.ts with protocol helper functions
2. ✅ Implement error-handler.ts
- ✅ Extract error classification logic
- ✅ Implement retry strategies
- ✅ Add error logging and reporting
3. ✅ Implement connection-manager.ts
- ✅ Extract connection pooling code
- ✅ Implement connection lifecycle management
- ✅ Add connection health monitoring
4. ✅ Implement command-handler.ts
- ✅ Extract SMTP command formatting and sending
- ✅ Split response parsing into separate methods
- ✅ Implement command pipeline management
5. ✅ Implement auth-handler.ts
- ✅ Extract authentication mechanism logic
- ✅ Implement PLAIN, LOGIN, OAUTH2 handlers
- ✅ Add credential management
6. ✅ Implement tls-handler.ts
- ✅ Extract TLS client connection handling
- ✅ Implement STARTTLS client functionality
- ✅ Add certificate validation
7. ✅ Implement create-client.ts
- ✅ Create factory function for client creation
- ✅ Implement dependency injection setup
- ✅ Add configuration validation
### Phase 3: Core Client Refactoring (Days 8-10) ✅
1. ✅ Refactor the main SmtpClient class
- ✅ Update constructor to create and initialize components
- ✅ Implement dependency injection for all modules
- ✅ Delegate functionality to appropriate modules
- ✅ Reduce core class to client lifecycle management
2. ✅ Update method delegation
- ✅ Ensure proper method delegation to handlers
- ✅ Implement proper error propagation
- ✅ Add missing method implementations
3. ✅ Implement cross-module communication
- ✅ Define clear interfaces for module interaction
- ✅ Ensure proper data flow between components
- ✅ Avoid circular dependencies
4. ✅ Verify functionality preservation
- ✅ Ensure all methods have equivalent implementations
- ✅ Add logging to trace execution flow
- ✅ Create test cases for edge conditions
### Phase 4: Legacy Compatibility and Testing (Days 11-12) ✅
1. ✅ Create facade in classes.smtp.client.ts
- ✅ Keep original class signature
- ✅ Delegate to new implementation internally
- ✅ Ensure backward compatibility
2. ✅ Add deprecation notices
- ✅ Mark legacy file with deprecation comments
- ✅ Add migration guide in comments
- ✅ Document breaking changes if any
3. ✅ Update documentation
- ✅ Create detailed documentation for new architecture
- ✅ Add examples of how to use the new modules
- ✅ Document extension points
4. ✅ Create comprehensive tests
- ✅ Ensure all modules have proper unit tests
- ✅ Add integration tests between modules
- ✅ Verify backward compatibility with existing code
2025-05-21 12:52:24 +00:00
## Testing Strategy
1. Unit Testing
2025-05-22 10:18:02 +00:00
- Create unit tests for each client module in isolation
- Mock socket connections and server responses
- Test authentication mechanisms independently
- Test error handling and recovery scenarios
2025-05-21 12:52:24 +00:00
2. Integration Testing
2025-05-22 10:18:02 +00:00
- Test interactions between client modules
- Verify proper command flow and response handling
- Test full SMTP client communication flow
- Test TLS/STARTTLS integration
2025-05-21 12:52:24 +00:00
2025-05-22 10:18:02 +00:00
3. Production Testing
- Create comprehensive client production test suite (similar to server tests)
- Test against real SMTP servers with various configurations
- Test authentication with different providers
- Performance and reliability testing
2025-05-21 12:52:24 +00:00
4. Compatibility Testing
2025-05-22 10:18:02 +00:00
- Test with existing code that uses the legacy SmtpClient class
- Verify backward compatibility with EmailSendJob integration
2025-05-21 12:52:24 +00:00
- Document any necessary migration steps
## Timeline Estimate
- Phase 1: 1-2 days
2025-05-22 10:18:02 +00:00
- Phase 2: 3-5 days
2025-05-21 12:52:24 +00:00
- Phase 3: 2-3 days
- Phase 4: 1-2 days
Total: 7-12 days of development time
## Success Criteria
1. All existing tests pass with the new implementation
2. No regression in functionality or performance
3. Each file is less than 300 lines of code
4. Improved code organization and documentation
5. Better separation of concerns between modules
2025-05-22 10:18:02 +00:00
6. Easier maintenance and extension of SMTP client functionality
7. Enhanced testability with modular components
8. Comprehensive production test suite for SMTP client
2025-05-21 12:52:24 +00:00
## Risks and Mitigations
2025-05-22 10:18:02 +00:00
### Risk: Breaking existing EmailSendJob integration
**Mitigation**: Comprehensive test coverage and backward compatibility facade with existing interface
2025-05-21 12:52:24 +00:00
### Risk: Performance degradation due to additional indirection
2025-05-22 10:18:02 +00:00
**Mitigation**: Performance benchmarking before and after refactoring, optimize hot paths
2025-05-21 12:52:24 +00:00
2025-05-22 10:18:02 +00:00
### Risk: Increased complexity due to distributed client code
**Mitigation**: Clear documentation and proper module interfaces, follow server refactoring patterns
2025-05-21 12:52:24 +00:00
2025-05-22 10:18:02 +00:00
### Risk: Connection pooling complexity in modular architecture
**Mitigation**: Careful design of connection-manager interface, thorough testing of connection lifecycle
### Risk: Time overrun due to authentication complexity
**Mitigation**: Incremental approach with working checkpoints, start with simpler auth mechanisms
2025-05-21 12:52:24 +00:00
## Future Extensions
Once this refactoring is complete, we can more easily:
2025-05-22 10:18:02 +00:00
1. Add support for additional SMTP authentication mechanisms (OAUTH2, SCRAM-SHA, etc.)
2. Implement advanced connection pooling strategies
3. Add comprehensive production test suite matching server coverage
4. Improve performance with targeted optimizations (pipelining, concurrent connections)
5. Create specialized client versions for different use cases (bulk sending, transactional)
6. Add client-side security features (connection validation, certificate pinning)
7. Implement advanced retry and fallback strategies
8. Add comprehensive monitoring and metrics collection