[TIL] Day 75 Supabase Realtime을 활용한 받은요청함 구현 및 트러블슈팅

2024.01.19 금

 

 

• 주제 : 받은 요청함 구현

 

• 기술적 의사 결정 1
  • 받은 요청(flirting)이 있을 때 그에 해당하는 내용을 띄워야 함
  • 자기 자신. receiver 입장에서의 데이터만 띄우면 됨
  • 상태가 UNREAD인 요청을 받은요청함에 랜딩할 때 READ로 변경
  • 상태가 ACCEPT, DECLINE인 요청 제외
  1. 요청 데이터를 다루는 flirting_list의 모든 데이터를 가져온 후 클라이언트단에서 필터링
     1. 장점
        • 데이터를 가져오는 함수를 작성할 때 크게 고민을 하지 않아도 됨
        • 통신시 예외처리 하는 함수를 따로 공부하지 않아도 됨. 러닝커브가 낮음
     2. 단점
        • 클라이언트단에서 모든 데이터의 필터링이 들어가기 때문에 코드가 길어짐
        • 상태를 관리하기 어려움
        • 필요 없는 데이터가 한번 찍힌 후 필터링 되어서 원하는 현태가 다시 찍힘
  2. 요청 데이터를 다루는 flirting_list의 모든 데이터를 가져온 후 서버단(API.ts 파일)에서 필터링
     1. 장점
        • 이 또한 통신시 예외처리 하는 함수를 따로 공부하지 않아도 됨. 러닝커브가 낮음
        • 클라이언트단에서 필요한 데이터의 형태만 찍힘
     2. 단점
        • 클라이언트단에서 서버단으로 시점이 이동한 것일 뿐, 필터링 하는 코드는 여전히 길다.
        • 오히려 더 상태관리나 어떤 것이 필터링 되었는지 판단하기 어려워 질 수 있음
  3. 통신 함수 자체에서 필터링 하여 필요한 데이터만 가져와서 그대로 씀
     1. 장점
        • 필터링 하는 함수가 추가적으로 필요 없어지므로 코드가 간결해짐
        • 필터링 하는 곳이 서버통신하는 함수에 있으므로 원하는 데이터가 아닐 시 해당 함수만 디버깅 하면 됨
        • 여러 테이블의 데이터를 원하는 형태의 데이터로 가공(합쳐서)할 수 있음
        • FK를 통해서 자동으로 필터링이 되는 데이터를 활용할 수 있음 (select)
          • select('*, custom_users!flirting_list_sender_uid_fkey(name, avatar, age)')
        • 원하는 형태로 정렬해서 가져올 수 있음 (order)
          • order('created_at', { ascending: false })
     2. 단점
        • supabase에서 사용하는 통신 함수에 대해서 공부가 필요함. 러닝커브가 높음 (from, select, update, order, eq, not, in, returns)
        • 가져오는 과정을 볼 수 없고 결과물만 찍히기 때문에 어느쪽의 함수가 문제인지 파악하지 어려움. 이 함수를 적을 때 결괏값을 예측해야 함
        • 원하는 형태로 100% 가공할 수 없음
        • ERD를 잘 설계해야함
  • 적용 결과
    • supabase 함수를 통해서 최대한 필터링된 데이터를 가져옴
    • 추가적으로 필터링이 필요한 것들이나, 간단한 필터링 같은 경우만 2차적으로 필터링
    • 필터링시 작성되는 코드의 길이가 많이 줄어들었고 명시적으로 표현됨
    • DB관리, ERD를 공부할 수 있었음 (RLS policy, Trigger, Schema Visualizer, PK FK, SQL 등)

 

 

• 기술적 의사 결정 2
  • 받은 요청함에서 실시간으로 요청이 들어올 때, 페이지 이동 없이 실시간으로 요청이 띄워지게 하는 방법
  1. 소켓
     1. 장점
        • 실시간 통신을 다룰 수 있다
     2. 단점
        • 완전 새로운, 시도해보지 못한 영역
        • 러닝 커브가 너무 높다
  2. supabase realtime 활용
     1. 장점
        • 이미 supabase를 활용하고 있으므로 호환성이 좋다
        • 쉬운 코드로 실시간 통신을 다룰 수 있다
     2. 단점
        • supabase가 비교적 최근 기술이기 때문에 정보가 많이 없다.
  • 적용 결과
    • supabase realtime에 대해서 간단하게 공부 후 바로 적용할 수 있었다.
    • 받은 요청함에서 DB의 변화를 감지하여 바로 리렌더링 시켜줄 수 있다.
    • poayload로 들어오는 데이터를 그대로 사용할 수 없었음
    • poayload를 트리거로 활용하여 실시간 통신이 감지되면 필요한 데이터를 커스텀하여 가져와서 뿌려주는 통신 함수 실행

 

 

• 트러블 슈팅
  • 문제
    • 받은요청함에 랜딩해 있을 때만 status를 READ로 바뀌어야 하는데 다른 페이지에 있어도 READ 처리 되는 현상 (알림 페이지와 연관이 되어 있는 부분이기에 영향이 있음. 의도한 현상이 아니었음)
  • 원인
    • 한번 열린 채널이 자동으로 닫히기까지 시간이 걸림
  • 해결
    • 다른 페이지로 이동시 useEffact 클린업 함수를 통해서 realtime 구독 해제 함수 실행