지난 주 잘 안 된 것 현황 공유

• 잘 안 된 것

1. JPQL native query 를 사용할때, 위치간 거리를 계산하는 함수인 mysql 내장함수인 ST_Distance_Sphere 전달할 수 없었음
   • 왜 안 되는지?
     • JPQL 사용시 데이터 베이스 벤더에 의존성을 피하기 위해서 개발된 언어로 MySQL 데이터베이스 내장 함수 호출 불가능
   • 어디까지 해봤는지?
     1. **하버사인 공식(Haversine Formula) 을 활용하여, jpql 전달 가능한 형태로 직접 연산하고 있음**
     2. QueryDsl 적용 후, ST_Distance_Sphere 내장 함수 사용 가능
   • 그래서 지금은 어떻게 되었는지 or 어떻게 해결했는지?

     • QueryDsl로 전환하여, 내장 함수를 사용할 수 있게 되었으나, 다중 Join과 Where문을 처리하는 방법에 대한 의문

     • Service에서 기술 스택과 경력 filter에 대한 분기 처리를 하는 방법과

     • Repository에서 분기 처리를 하는 방법 중 어느 것이 일반적으로 타당한지

       ⇒ 자세한 조건은 DB / 재가공은 service Layer

       ⇒

• 메인 페이지 카드 리스트 UI 변경

• 프로젝트에서 사용하는 기술 스택/라이브러리와, 선정 이유를 적어주세요.

  • 기술 스택
    • FE
    • BE

• 이번 주 한 일

  • 팀 전체
    • 채팅 서비스 기술 테스트 및 구현
    • 모임 CRUD API 구현
    • 소셜 로그인 구현 (Refresh 토큰 포함)
  • 팀원 개인별
    • 송두용
    • 유하정
    • 천옥수
    • 최산하
    • 강성지
    • 이예진

  💪🏻 프로젝트 별 강점 5가지

  • 소셜로그인
  • 메인 페이지 meetings 조회 관련 기능
  • 모바일 UI
  • Web Socket
  • CI/CD 환경을 통한 배포 자동화 → 개발에 집중

• 이외에도 기술적인 방향을 잡기 위한 질문을 정리해오시면 가장 좋습니다!

  <aside> 📍 1. 다중 Filter 적용시, IN 연산자 DB 조회에 대한 정책적인 고민

  </aside>

  • 문제 상황
    • 기술 스택이 (Java, React) 로 2개 넘어오는 경우, Java가 포함된 글과 React가 포함된 글을 OR로 연결하여 모두 조회
    • 타 사이트(점핏, 원티드) 확인 결과, IN 연산자를 통해 중복 필터 적용
  • 해결 방안

    • GroupBy + Having 절을 사용하여, 2개의 기술이 모두 포함되는 row를 조회하는 경우, 두 스킬을 포함한 3개 이상의 데이터 추출 불가

    • 기존의 IN 방식으로 대략 50개 정도 퍼온 뒤, Java에서 데이터를 가공하는 방법

      → 불필요한 DB 조회가 많아질 우려 (성능 저하)

    • 기존의 IN 방식을 사용하여, 해당 스킬이 하나라도 걸리는 경우를 모두 출력

      → 현재 이 방법이 적용된 상태이며, 해당 방법이 적절한지 여쭙고 싶습니다!

  <aside> 📍 2. 채팅 구현과 관련된 고민

  </aside>

  • 문제 상황
    • 채팅방 메시지 가져오기 방식 :
      1. 모임에 가입하기
      2. 모임에 가입하여 채팅방에 접속할 권리를 얻기
      3. 채팅방 화면 전환(화면 그리는 동시에 웹소켓 연결 시작 -> 입장을 별도로 할 이유가 없음)
      4. HTTP GET 채팅방 메시지 가져오기 (최근 20개)
      5. 웹소켓 연결 시 SUBSCRIBE 채팅방 메시지 구독하기
      6. SEND 채팅방 메시지 보내기
      7. 구독한 메시지 받기 → 채팅 목록에 추가
      8. 해당 화면이 destructure 될 경우, websocket disconnect 완료(subscribe 종료)
    • 웹소켓 연결 이전 과거 채팅 내역을 보여줘야 합니다.
    • 웹소켓 연결 이후의 받은 채팅 내역의 경우에는 websocket으로 받아야 합니다.
  • 해결 방안
    • 현재는 과거의 채팅 내역와 웹소켓 접속 이후의 채팅 내역을 받기 위해서 HTTP와 WS 두가지 통신방법을 사용하고 있습니다.
    • 두가지 방식으로 한 종류의 데이터를 받는 것이 맞을까 고민이 됩니다.

  <aside> 📍 3. 리액트 쿼리- 효율적인 데이터 캐싱 방법

  </aside>

  • 문제 상황:
    • 메인 페이지에서 모임 리스트를 조회할 때, 유저가 설정한 좌표(지도의 중심좌표)를 기준으로 서버로부터 가장 가까운 16개의 모임 리스트를 받아오고 있습니다.
    • 리액트 쿼리의 쿼리키는 서버로부터 받아오는 데이터를 캐싱할 때, 데이터를 구분할 수 있도록 부여하는 키로 알고 있습니다.
    • 현재 모임 리스트 조회 방식은 좌표가 변경될 때 마다 받아오는 데이터가 달라질 수 있기 때문에, 각 호출마다 매번 다른 키를 부여해야 한다고 생각했습니다.
    • 그 결과, 호출 시 매번 서버로부터 데이터를 받아오고, 기존의 캐싱된 데이터는 활용하지 못할 것이라고 생각합니다.
  • 해결 방안
    • 이 경우 캐싱된 데이터를 올바르게 활용할 수 있는 대안이 있는지 궁금합니다.
    • 백엔드에서 캐싱을 해주는 방법이 있다.
    • 프론트에서 캐싱하는 정보: 유저 정보 등 자주 변하지 않는 정보

• 숙제: 멘토링 결과 다음 주까지 해올 일

  • 팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)

  • 팀원 개인별로 작성해 주세요.
    • 송두용
    • 유하정
    • 천옥수
    • 최산하
    • 강성지
    • 이예진