프론트엔드 개발 포트폴리오 | 모각코 매칭 서비스

내일배움캠프 4기 웹 개발 과정 React 트랙 수료생 최종 프로젝트 '모코'를 소개합니다.
Sep 04, 2023
프론트엔드 개발 포트폴리오 | 모각코 매칭 서비스
notion image
 

모각코(모여서 각자 코딩하자!) 위한 매칭 서비스 “MOCO

MOCO(모코)는 개발자 문화 중 하나인 모각코 모임을 찾아 코딩 메이트를 매칭해주는 플랫폼입니다.
 

🛠️ 아키텍쳐

notion image

🛠️ 주요 기술 및 기술적 의사 결정

React Query

도입 배경
  • 처음에는 파이어베이스 내장 API를 사용했지만, 페이지와 컴포넌트가 여러 갈래로 나눠짐에 따라 서버에 불필요한 데이터 요청이 잦아짐. 이를 한 번에 해결할 수 있는 기술이 필요해짐.
기술 선정 과정
  • Redux 상태를 전역으로 사용할 수 있지만 보일러 플레이트 코드가 길고 핵심 데이터를 서버에 요청해서 사용해야만 하는 구조였기 때문에 보다 더 간편한 것을 원했음으로 패스함.
  • React Query 1) 핵심 데이터가 서버에 있다는 점 2) 비동기 통신에 특화되어 예외 처리가 쉽다는 점 3) 캐싱 기능을 이용해 데이터 요청을 최소화할 수 있으며 전역 상태 관리가 필요하지 않게 된다는 점 4)Fresh한 데이터가 필요할 때도 옵션을 사용해 새로고침이 없이 데이터를 최신화 할 수 있다는 점 위 4가지 이유로 리액트 쿼리를 도입했음. 리액트 쿼리 도입 결과, useQuery 커스텀훅 + 캐싱 기능으로 props 드릴링과 과도한 데이터 요청을 해결할 수 있었음

Recoil

도입 배경
  • React Query를 사용했지만 기능이 늘어나다보니 겹쳐지는 DB정보들을 좀 더 쉽고 간단명료하게 정리해야 할 필요성(리팩토링)을 느낌.
기술 선정 과정
  • Redux 상태를 전역으로 사용할 수 있지만 보일러 플레이트 코드가 길고 핵심 데이터를 서버에 요청해서 사용해야만 하는 구조였기 때문에 보다 더 간편한 것을 원했으며 시간 관계상 빠르게 정리할 수 있는 상태 관리 라이브러리를 찾아야 했으므로 패스함
  • Recoil 현재 사용하고 있는 Hooks들을 보다 쉽고 안정적이면서 남아있는 시간 내에 빠르게 습득할 수 있는 Recoil이 현 상황에서는 가장 이상적인 상태관리 라이브러리라고 판단하여 적용

Antd Design

도입 배경
  • 프로젝트 초반에 프로젝트 기획 및 디자인 최종 결정이 미뤄짐에 따라 빠르게 UI를 구현할 수 있는 수단이 필요했음.
기술 선정 과정
  • UI 라이브러리 선택 기준 1. 빠른 개발 속도를 위해 사용법이 아주 간단할 것 2. 기본으로 제공하는 컴포넌트 구조가 단순할 것 3. 최종 디자인이 나오면 커스텀할 수 있어야 하기 때문에 기본으로 제공하는 디자인이 튀지 않을 것
  • Ant Desgin 선택 mui도 고려했지만 작업 시간을 단축시키는 것이 목적이었기 때문에 mui보다 사용법이 간단하고 레이아웃을 제공해주는 Ant Desgin을 선택했음. 사용 결과, 빠르게 기초적인 컴포넌트들을 만들 수 있었고 기능 개발을 시작할 수 있었다.

Quill

도입 배경
  • 사용자들이 댓글보다는 비교적 긴 텍스트를 작성할 것으로 예상했고, textarea를 사용할 때보다 텍스트 작성 경험을 좋게 만들어줄 기술이 필요했음.
기술선정 과정
  • 에디터 라이브러리 선정 기준 1. 추가로 설정할 것이 적은 것 2. 한글지원이 잘 되는 것 3. 위지윅 기능을 지원하는 것 4. 안정적인 것
 
  • Quill 선택 Toast Ui Editor와 Quill 사이에서 고민을 했음. Toast Ui Editor는 NHN에서 만들었기 때문에 한글 입력이 안정적이고 ui도 예뻤음. 하지만 NPM Trend로 확인해봤을 때 Quill이 압도적으로 많이 사용되었기 때문에 안정성이 보장되었고 레퍼런스 자료가 많을 것으로 판단해 Quill을 선택했음. Quill은 선정 기준 4가지에 다 부합했고 도입 결과, Quill을 사용해 줄바꿈 처리나 텍스트 스타일링에 고민하지 않고 원하는 결과를 얻을 수 있었음.

🚀 트러블 슈팅

글 작성시 더블클릭 방지

문제현상

write 페이지에서 ‘작성 완료’ 버튼을 여러 번 클릭하면 클릭한 횟수대로 게시글이 게시되었다.
notion image
 

문제원인

버튼이 클릭될 때마다 글이 작성되는 이벤트가 발생하기 때문

해결방법

react 에서 lodash를 사용할 때 유의할 점
  • lodash 라이브러리의 debounce 사용
  • 리렌더링 되는 컴포넌트 내에 debounce를 정의한 함수가 있고, 해당 컴포넌트가 state에 따라 리렌더링이 된다면 debounce 함수도 재생성되면서 debounce가 초기화
  • 이 버그를 방지하기 위해서는 useCallback을 사용함 useCallback을 이용하여 state가 바뀜에도 debounce함수는 재생성이 되지 않도록 하여 debounce가 초기화 되지 않도록 막음
 
  • 실제 debounce 를 사용할 때에도 debounce 내로 값이 들어가면 초기화 시켜 빈 값이 메모제이션 되는 경우가 발생함
  • hadleSubmit 함수의 디펜던시 배열에 맨 마지막에 들어가는 값인 partyDesc 을 넣어 해결
notion image

Before & After

Before
문제 현상 gif 확인
 
After
notion image
 

참고사항

 
북마크 업데이트 속도 개선

문제 현상

북마크 버튼을 클릭했을 때 그 반응 속도가 늦어져서 서비스 자체가 느리다는 인상을 줌

문제 원인

JS 내 prefomance API를 사용해서 확인해본 결과,
 
  1. 북마크 업데이트 요청에 대한 응답이 오고 난 뒤에야 UI가 변경되고 있음
  1. 북마크 업데이트 응답 속도는 약 180ms이었고 늦는 경우 200ms였음
 
유저 입장에서는 북마크 버튼을 클릭하고 나서 늦으면 0.2초 후에 반응하는 UI를 경험해야 했음.

해결 방법

velog 등 다른 웹에서 북마크 버튼을 클릭하고 반응 속도를 측정해보니
빠르면 80ms 늦어도 100ms로 속도감이 좋았음.
 
현재 북마크 응답 속도가 180 ~ 200ms 사이기 때문에 다른 웹에서 만큼
빠르게 반응하기 위한 방법으로 낙관적 업데이트를 선택했음.
파이어베이스 속도를 높이는 것보다 쉽고 더 효과적인 방법이라고 판단했음.
 
마침 프로젝트에서 React-Query를 사용하고 있었기 때문에
queryClient.setQueryData를 이용해
기존 데이터에서 해당 게시물의 북마크값만 1씩 증감해주도록 했음.
 
위 코드가 북마크 업데이트 함수가 끝나기 전에 먼저 실행될 수 있도록 해
북마크 업데이트 요청이 완료되기 전에 UI단에서 변경된 북마크 값을 렌더링할 수 있었음.

Before & After

결과 : 체감 속도 약 2배 감소 (기존 180~200ms에서 80~100ms로) (Optimistic Update : 유저가 보는 화면에서 UI가 변경되는 속도) (Server Update : 실제로 요청이 완료되는 속도)
notion image
 
비교 영상 (좌 : before / 우 : after)
 

코드

기존 코드
notion image
추가 코드
notion image
북마크 더블클릭 시 숫자 증감 이슈

문제 현상

북마크 클릭 연타 시 숫자증감 이상

문제 원인

북마크 연타 시에 내부 로직에서 발생하는 에러

해결 방법

debounce 함수를 만들어 더블클릭 방지 및 usecallback 의 디펜던시 배열에 bookmark 입력
notion image
 

Before & After

Before
북마크 버튼이 계속 연타됨과 동시에 북마크 숫자 이상 발생
notion image
 
After
debounce 함수를 사용하여 맨 마지막 이벤트만 받게 함으로써 이상 해결
notion image

참고 사항

 

🧑‍💻 👩‍💻 팀원소개

Share article
Subscribe to our newsletter
RSSPowered by inblog