# endorserServer.ts Pre-Migration Audit

## Service Overview
- **File**: `src/libs/endorserServer.ts`
- **Purpose**: Endorser server interface and utilities for claims, contacts, and server communication
- **Complexity**: High (1510 lines)
- **Migration Priority**: High (Services category)

## Current State Analysis

### Phase 1: Database Migration Assessment
- **Status**: ⏳ NEEDS MIGRATION
- **Issues Found**:
  - Uses `logConsoleAndDb` from `../db/databaseUtil` (line 31, 443)
  - Uses `PlatformServiceFactory.getInstance()` for database operations (line 1455)
  - Raw SQL query: `"UPDATE contacts SET seesMe = ? WHERE did = ?"` (line 1458)

### Phase 2: SQL Abstraction Assessment
- **Status**: ⏳ NEEDS MIGRATION
- **Issues Found**:
  - Raw SQL query in `setVisibilityUtil` function (line 1458)
  - Direct database operation without service abstraction

### Phase 3: Notification Migration Assessment
- **Status**: ⏳ NEEDS MIGRATION
- **Issues Found**:
  - Direct `$notify` calls in `getHeaders` function (line 405)
  - Hardcoded notification messages and timeouts
  - No notification helpers or constants used

### Phase 4: Template Streamlining Assessment
- **Status**: ✅ NOT NEEDED
- **Evidence**: No template code found (service file)
- **Actions Required**: None

## Technical Analysis

### Database Operations
```typescript
// Legacy databaseUtil usage
import { logConsoleAndDb } from "../db/databaseUtil";
logConsoleAndDb("Something failed in getHeaders call...", true);

// PlatformServiceFactory usage
const platformService = PlatformServiceFactory.getInstance();
await platformService.dbExec(
  "UPDATE contacts SET seesMe = ? WHERE did = ?",
  [visibility, contact.did],
);
```

### Notification Operations
```typescript
// Direct $notify calls
$notify(
  {
    group: "alert",
    type: "danger",
    title: "Personal Data Error",
    text: notifyMessage,
  },
  3000,
);
```

### Code Complexity
- **Lines**: 1510 lines
- **Functions**: 40+ exported functions
- **Imports**: 15+ imports including legacy patterns
- **Database Operations**: 1 raw SQL query
- **Notification Usage**: Direct $notify calls

### Key Functions Requiring Migration
1. **`getHeaders`** (line 405): Notification migration needed
2. **`setVisibilityUtil`** (line 1436): Database and SQL migration needed
3. **`logConsoleAndDb` usage** (line 443): Database migration needed

## Migration Plan

### Phase 1: Database Migration
1. **Replace Legacy Imports**
   - Remove `logConsoleAndDb` import
   - Replace with logger utilities

2. **Update Database Operations**
   - Replace `PlatformServiceFactory.getInstance()` with service injection
   - Update `setVisibilityUtil` to use service methods

### Phase 2: SQL Abstraction
1. **Replace Raw SQL**
   - Extract contact visibility update to service method
   - Replace raw SQL with service call

### Phase 3: Notification Migration
1. **Add Notification Helpers**
   - Import notification constants and helpers
   - Replace direct `$notify` calls with helper methods
   - Use notification constants for messages

2. **Update Notification Patterns**
   - Extract notification messages to constants
   - Use timeout constants instead of hardcoded values

## Estimated Migration Time
- **Phase 1**: 10-15 minutes
- **Phase 2**: 5-10 minutes
- **Phase 3**: 10-15 minutes
- **Total Time**: 25-40 minutes

## Risk Assessment
- **Medium Risk**: Large service file with multiple migration points
- **Breaking Changes**: Database and notification pattern changes
- **Performance Impact**: Minimal (service modernization)

## Success Criteria
- [ ] Legacy databaseUtil imports removed
- [ ] PlatformServiceFactory usage replaced with service injection
- [ ] Raw SQL query replaced with service method
- [ ] Direct $notify calls replaced with helper methods
- [ ] Notification constants used for messages
- [ ] Linting passes with no errors
- [ ] Service functionality preserved

## Migration Notes
- Large service file requiring careful migration
- Multiple functions need database and notification updates
- Service is critical for server communication
- Need to maintain backward compatibility during migration

---

**Audit Date**: 2024-12-19
**Auditor**: Migration System
**Status**: Ready for Phase 1, 2, & 3 migration