Follow Data Model Analysis

Current State Comparison

Seeding Script vs App Code

Field	Seeding Script	App Code (guardianFollowService)	App Code (caseLikeService)	Status
id	✅ Required	✅ Auto-generated (${userId}_${guardianId})	✅ Auto-generated (${userId}_${caseId})	⚠️ INCONSISTENT
userId	✅ Required	✅ Required	✅ Required	✅ Match
caseId	✅ Optional	❌ Missing	✅ Required	⚠️ INCONSISTENT
guardianId	✅ Optional	✅ Required	❌ Missing	⚠️ INCONSISTENT
followType	✅ Required	✅ Required (['like'])	✅ Required (['like'])	✅ Match
notificationsEnabled	✅ Optional	❌ Missing	❌ Missing	⚠️ INCONSISTENT
createdAt	✅ Required	✅ Required	✅ Required	✅ Match
updatedAt	✅ Optional	❌ Missing	❌ Missing	⚠️ INCONSISTENT

Issues Identified

1. ID Generation Strategy

• Seeding: Uses normalized ID from generator (flw_abc123)
• App Code: Uses composite key (${userId}_${caseId} or ${userId}_${guardianId})
• Question: Which approach should we standardize on?
  • Option A: Normalized IDs (better for queries, consistent with other entities)
  • Option B: Composite keys (simpler, prevents duplicates automatically)
  • Recommendation: Use composite keys for follows (simpler, prevents duplicate follows)

2. Missing notificationsEnabled in App Code

• Seeding: Has notificationsEnabled (optional, defaults to true)
• App Code: Doesn't set notificationsEnabled when creating follows
• Impact: New follows created via app won't have notification preference set
• Recommendation: Add notificationsEnabled: true as default in app code

3. Missing updatedAt in App Code

• Seeding: Has updatedAt (optional)
• App Code: Doesn't set updatedAt when creating follows
• Impact: No tracking of when follow preferences change
• Recommendation: Set updatedAt to createdAt when creating, update when preferences change

4. Follow Type Array

• Current: followType: ['like'] (array with single value)
• Question: Should this be:
  • Option A: Array (allows multiple types: ['like', 'subscribe'])
  • Option B: Single value (simpler: followType: 'like')
• Recommendation: Keep as array for future extensibility (subscribe, bookmark, etc.)

Recommendations

1. Standardize ID Generation

Recommendation: Use composite keys in app code, but document both approaches

• Composite keys: ${userId}_${caseId} or ${userId}_${guardianId}
• Prevents duplicate follows automatically
• Easier to check if follow exists
• Keep normalized IDs in seeding for testing

2. Add Missing Fields to App Code

Recommendation: Update app code to include:

{
  userId,
  caseId, // or guardianId
  followType: ['like'],
  notificationsEnabled: true, // Default to true
  createdAt: new Date().toISOString(),
  updatedAt: new Date().toISOString() // Same as createdAt initially
}

3. Follow Type Structure

Recommendation: Keep as array for future extensibility

• Current: ['like']
• Future: ['like', 'subscribe'] (user can like AND subscribe)

4. Notification Preferences

Recommendation:

• Default to true (users want notifications by default)
• Allow users to toggle per follow
• Update updatedAt when preference changes

Questions for User

1. ID Strategy: Should we use composite keys (${userId}_${caseId}) or normalized IDs (flw_abc123)?

   • My recommendation: Composite keys (simpler, prevents duplicates)

2. Follow Type: Should followType be an array or single value?

   • My recommendation: Keep as array (future extensibility)

3. Notifications Default: Should notificationsEnabled default to true?

   • My recommendation: Yes (users want notifications by default)

4. Update Follows: Should follows be updatable (to change notification preferences)?

   • Currently: Firestore rules prevent updates (allow update: if false)
   • My recommendation: Allow updates for notificationsEnabled and updatedAt only