주요 기술
로그인 /회원가입
마이페이지
리뷰페이지
미팅룸
채팅
사이드바
기술적 의사결정
Next.js
•
프레임워크로서 번들링, 컴파일 등과 같은 툴링을 추상화하고 자동으로 구성하기 때문에 애플리케이션을 만드는데 보다 집중할 수 있습니다.
•
서버 사이드 랜더링(SSR)과 정적 사이트 생성(SSG), 서버컴포넌트 등 React의 새로운 기능을 사용할 수 있습니다.
TypeScript
•
서로 다른 코드간의 관계를 표현하기 위해 사용됩니다.
•
가장 일반적인 오류인 유형 오류, 오타 등의 발생을 최소화하기 위해 사용하였습니다.
•
코드가 실행되기 전에 실행되어 타입이 올바른지 확인할 수 있어 사용하였습니다.
Zustand
•
간단한 설정으로 클라이언트 컴포넌트간 이동이 필요한 데이터를 관리할 수 있습니다.
•
redux의 reduxDevTools로 디버깅이 가능하기 때문에 오류 추적에 용의합니다.
•
Jotai와 Recoil은 전역상태에 바로 접근하기 때문에 어느 단계에서 변화가 일어났는지 추적이 어렵습니다.
•
따라서 저희 조는 Zustand로 상태 관리를 선택했습니다.
React-Query
•
불필요한 서버 요청을 막기 위해서 사용되었습니다.
•
서버에서 불러온 데이터를 zustand로 상태를 관리한다면 같은 데이터를 두 번 관리해야 하는 문제점이 발생하기 때문입니다.
•
하나의 쿼리키를 사용하여 서버에서 데이터를 받아옴으로서 중복된 서버 요청 없이 데이터를 사용할 수 있어 선택하였습니다.
Supabase
•
데이터베이스, 인증, 스토어 등 백엔드 개발에 필요한 기능을 간편하게 이용할 수 있어 선택하였습니다.
•
실시간 기능을 제공하여 기능을 작동시킨 사람이 아니어도 추적이 가능한 서비스를 제공하고 있습니다.
•
Firebase는 검색기능을 제공하지 않기 때문에 데이터를 선별한 뒤 가져올 수 있는 Supabase를 선택하였습니다.
UNIVCERT
•
학교 인증을 통해 유저를 대학생으로 한정하고, 신뢰성 있는 미팅 홈페이지로 만들기 위해 선택했습니다.
Tailwind-CSS
•
일관적인 형태의 간편한 CSS 구현이 가능합니다.
Kakao-map
•
검색된 장소에 대한 자세한 장소를 얻을 수 있는 API를 선택하였습니다.
•
네이버는 더 적은 데이터를 주기 때문에 카카오 API를 선택하였습니다.
트러블슈팅
React-query
도입 이유 | 서버에서 받아오는 데이터의 효율적인 관리와 로직의 결과를 의도대로 얻을 수 있습니다. | |
문제 상황 | 유저의 정보 등 서버에서 데이터를 가져올 때 반복되는 요청으로 인한 과도한 요청이 발생하며, 랜더링이 될 때마다 null로 초기값이 변경되어 로직에 오류를 발생시켰습니다. | |
해결 방안 | 서버에서 받는 데이터는 React-query로 관리하고, 클라이언트 컴포넌트 사이에서 잠시 이동하는 데이터는 Zustand로 관리하여 데이터의 상태를 효율적으로 관리하는 것이 좋습니다. | |
의견 조율 | 유저와 관련된 정보는 React-query로 관리하고 Zustand로 저장하거나, 중복하여 요청하지 않도록 코드를 모두 리펙터링 하는 것을 조율하였습니다. | |
의견 결정 | 서버에서 받는 데이터는 React-query로 관리하며, 중복하여 요청하지 않도록 코드를 모두 정리합니다. 또한 선언형(fetch)과 명령형(mutation) 쿼리를 구분하여 보관함으로서 데이터의 이동을 쉽게 파악할 수 있게 합니다. |
팀원
팀 노션 :
발표
발표준비(04.30)