친구 요청 및 친구 관리 기능 구현 과정

1. 프로젝트 요구사항 재정리

처음에는 친구 요청과 친구 관리를 단순하게 처리하려 했으나, 구현 과정에서 여러 경우의 수를 고려해야 했습니다:

• 친구 요청 상태 관리 (type 필드):
  • type=0: 대기 중
  • type=1: 수락(친구 관계 형성)
  • type=-1: 거절
• 친구 요청과 친구 관리의 분리:
  • 친구 요청과 실제 친구 목록을 구분해 설계해야 함을 깨달았습니다.

---

2. 의사결정 변화

1. 친구 요청 상태 관리 방식

   • 초기 설계: type=-1로 상태를 유지하고 데이터베이스에 남겨두기.
     • 문제점: 거절된 요청이 데이터베이스에 쌓이면서 관리가 복잡해지고, 성능 저하 우려
     • 결정: 거절된 요청은 삭제하는 방식으로 변경

2. 친구 관계 형성

   • 초기 설계: type=1로 요청 상태를 업데이트한 뒤, 별도로 친구 관계를 처리하지 않음
     • 문제점: 요청 상태를 업데이트하는 것만으로는 명확히 친구 관계를 관리하기 어려움
     • 결정: 요청 수락 시 요청을 삭제하고, 별도의 Friend 모델로 관계 관리.

3. 중복 요청 방지

   • 초기 설계: type 상태를 활용해 요청을 중복 생성하지 않도록 함
     • 문제점: 같은 요청을 재활용할 경우 클라이언트와의 통신이 복잡해짐
     • 결정: 요청은 삭제하되, 언제든 새로운 요청을 생성 가능하도록 설계

4. 프론트엔드 연동 고려

   • 초기 설계: 프론트엔드에서 user_id 기반으로 요청 처리
     • 문제점: 여러 요청이 있을 경우 특정 요청을 구분하기 어려움
     • 결정: 요청 고유 ID(friend_request_id)를 사용해 명확히 처리

---

3. 최종 설계

1. 친구 요청 로직 (FriendRequestAPIView)

   • 친구 요청 생성:
     • 이미 친구이거나 대기 중인 요청이 있는 경우 요청 불가
   • 요청 조회:
     • 현재 사용자가 받은 대기 중 요청만 반환
   • 요청 상태 변경:
     • 수락 시:
       • 요청 삭제.
       • Friend 모델에 관계 생성
     • 거절 시:
       • 요청 삭제.

2. 친구 관리 로직 (FriendAPIView)

   • 친구 목록 조회:
     • 현재 사용자의 친구 목록 반환
   • 친구 삭제:
     • 양방향 관계를 모두 삭제

---

4. 배운 점

1. 로직을 명확히 분리해야 유지보수가 쉬움:

   • 친구 요청과 친구 관리를 분리하여 각각의 책임을 명확히 함

2. 데이터베이스 정리의 중요성:

   • 거절된 요청을 삭제하여 불필요한 데이터가 쌓이는 것을 방지
   • 삭제를 통해 요청을 재활용할 필요가 없으므로 로직 단순화

3. 프론트엔드와의 협업:

   • 고유 ID(friend_request_id)를 사용하여 요청을 명확히 처리함으로써 클라이언트와의 통신 간소화

4. 의사결정은 반복적이고 점진적인 과정:

   • 초기 설계에서 부족했던 부분들을 구현과 테스트 과정을 통해 보완

---

5. 개선 방향

1. 알림 기능 추가:
   • 친구 요청 수락/거절 시 알림을 통해 사용자 경험 개선
2. 친구 추천 기능:
   • 친구 목록을 기반으로 게임 추천 기능 구현