프로젝트 매칭 품질 개선

프로젝트 매칭 방식 변경됨 매칭된 프로젝트 조회 속도가 빨라짐 유저에게 약간의 딜레이가 필요하다고 기획에서 판단 따라서, 매칭된 프로젝트 개수는 최대 10개 넘어오지만 이를 3초의 의도적인 딜레이를 주고 노출되도록 프론트 수정

피드 내용만으로는 백엔드의 변경사항을 이해하기 어려웠는데, 쉽게 풀어서 구두로 설명해주셔서 도움이 된 것 같습니다. 변경된 구조를 보고 유저의 대기열은 매칭이 될 때까지 최대 24시간을 기다리는 것보다는 원하는 조건의 프로젝트가 생겼을 때, 알림을 받는 용도로 사용하는 것이 더 적합하다고 판단됩니다. 개발자 분들께서 위와 같이 변경해주시면 감사하겠습니다 :)

Q. 어차피 트리거 -> rpc function을 호출하는 플로우인데 굳이 트리거 -> edge function -> rpc function로 edge function을 중간에 거치는 방식으로 구현했는가? A. 프로젝트 생성과 매칭 대기열 알림을 ⭐️비동기⭐️로 수행하기 위해서입니다! ✅️ 왜 비동기로 수행했는가 알림은 프로젝트 생성 여부와 관련 없는, 영향을 주어서는 안되는 별개의 로직입니다. 대기열에 등록된 유저가 많다고 가정할 때, 알림으로 인해 프로젝트 생성 결과가 지연되어 유저의 경험을 해칠 가능성이 있습니다. 따라서, 알림 로직을 비동기로 분리했습니다. ✅️ edge function은 비동기에서 어떤 역할을 수행하는가 트리거 + rpc function 조합은 postgreSql 구조상 프로젝트 생성과 동기로 진행됩니다. 따라서 edge function을 통해 rpc function을 비동기로 호출하도록 했습니다. ✅️ 어느 시점에 호출하는가 처음에는 webhook 기반으로 edge function을 호출하고자 했습니다. 🤔 뭘 기준으로 webhook이함수를 호출하도록 하면 될까? 후보) insert - 프로젝트 데이터가 생성될 때 project의 데이터 만으로는 해당 프로젝트에서 어떤 직군을 매칭으로 모집하고자 하는지 판단하기 어려웠습니다. 따라서 반드시 vacancies 또는 participants 테이블의 정보가 필요했습니다. (vacancies가 좀 더 적합) 그러나 프로젝트 생성의 로직 호출 순서에 의하면 프로젝트 데이터는 생성 -> 초대 처리 -> vacancies 생성이기 때문에 프로젝트 생성 시점에 vacancies는 생성되지 않았을 가능성이 있어 insert는 🚫부적합한 방법이라고 판단했습니다. 🤔 그렇다면 vacancies 생성 후에 알림 로직이 수행되어야 할 텐데 이를 어떻게 보장할 것인가? ⭐️ProjectStatus enum 'draft'(임시저장) 추가⭐️ 프로젝트 생성(draft) -> 관련 데이터 생성 완료 -> 프로젝트 상태 업데이트 (pending) 😲 그런데 webhook에는 특정 컬럼의 update에 대해서만 트리거를 수행하는 기능이 없는 문제 발생! (update 밖에 모르는 너란 녀석...!) 프로젝트 데이터의 변경은 매우 빈번한데, 그 때마다 알림에 불필요한 변경으로 인해 edge function이 호출되는 것은 막심한 손해...! 따라서 최종적으로 특정 컬럼의 상태 변경을 인식할 수 있는 db 트리거를 기반으로 프로젝트의 상태가 draft에서 pending으로 바뀔 때, edge function을 걸쳐 알림을 보내는 rpc function이 호출되도록 구현했습니다! 👍