44 lines
3.0 KiB
Markdown
44 lines
3.0 KiB
Markdown
|
# SPEC: Refactor Alert CRUD to Service Layer
|
||
|
|
|
||
|
|
## Goal
|
||
|
|
Refactor the `src/backend/routers/alerts.py` file to move business logic and data access into a dedicated `src/backend/services/alert_service.py` file. This aligns the alerting module with the existing service-oriented architecture used in the rest of the project (e.g., `SentimentService`, `RotationService`).
|
||
|
|
|
||
|
|
## Exact Requirements
|
||
|
|
1. **Create `src/backend/services/alert_service.py`**:
|
||
|
|
- Implement an `AlertService` class containing methods for all current alert operations.
|
||
|
|
- Methods required:
|
||
|
|
- `get_user_alerts(watchlist_id, status, page, page_size, user_id)`
|
||
|
|
- `create_alert(body, user_id)`
|
||
|
|
- `get_alert(alert_id, user_id)`
|
||
|
|
- `update_alert(alert_id, body, user_id)`
|
||
|
|
- `resolve_alert(alert_id, user_id)`
|
||
|
|
- `dismiss_alert(alert_id, user_id)`
|
||
|
|
2. **Encapsulate Authorization**:
|
||
|
|
- Move the ownership verification logic (`_require_watchlist_owner`) into the service layer or a shared security service.
|
||
|
|
3. **Encapsulate Data Access & Transformation**:
|
||
|
|
- Move all `execute_query`, `execute_one`, and `execute_command` calls into the `AlertService`.
|
||
|
|
- Handle the mapping of database rows to `AlertResponse` and `AlertListResponse` models within the service.
|
||
|
|
4. **Update `src/backend/routers/alerts.py`**:
|
||
|
|
- Remove direct database calls and business logic.
|
||
|
|
- Inject/instantiate `AlertService` and delegate all requests to it.
|
||
|
|
- Maintain the existing FastAPI route definitions and dependency injection (e.g., `get_current_user`).
|
||
|
|
5. **Maintain Feature Parity**:
|
||
|
|
- The API behavior (endpoints, status codes, response models) must remain identical to the current implementation.
|
||
|
|
|
||
|
|
## Acceptance Criteria
|
||
|
|
1. **Code Structure**: `src/backend/routers/alerts.py` contains only routing and request/response handling.
|
||
|
|
2. **Service Implementation**: `src/backend/services/alert_service.py` is the single source of truth for alert business logic.
|
||
|
|
3. **Test Pass Rate**: All tests in `src/backend/tests/test_alerts.py` must pass (including the previously failing tests).
|
||
|
|
4. **No Regressions**: All CRUD operations (Create, Read, Update, Delete, Resolve, Dismiss) must function exactly as before.
|
||
|
|
|
||
|
|
## Constraints & Non-Goals
|
||
|
|
- **Non-Goal**: Do not change the database schema.
|
||
|
|
- **Non-Goal**: Do not change the external API contract (URLs, JSON structure, status codes).
|
||
|
|
- **Constraint**: Maintain existing error handling patterns (e.g., 404 for missing resources, 403/404 for ownership issues).
|
||
|
|
|
||
|
|
## Recommended Implementation Approach
|
||
|
|
1. **Phase 1: Service Creation**: Implement the `AlertService` in `src/backend/services/alert_service.py` by copying logic from the router, but parameterizing it for the service methods.
|
||
|
|
2. **Phase 2: Router Migration**: Replace the body of each router function with a call to the corresponding `AlertService` method.
|
||
|
|
3. **Phase 3: Cleanup**: Remove the old `_require_watchlist_owner` helper from the router.
|
||
|
|
4. **Phase 4: Verification**: Run the existing test suite.
|