C2C 카 쉐어링 중개 플랫폼 - 타, 이거

프로젝트 기간

• 2022.08.26 ~ 2022.10.07

팀구성

이름	깃허브 주소	포지션
손성우	https://github.com/sungkong	Back-End
정윤혁	https://github.com/tanibourne	Back-End
최준우	https://github.com/gitpher	Back-End
심채운	https://github.com/Sim0321	Front-End
권익현	https://github.com/kwonih1020	Front-End
허지연	yeooon02@gmail.com	UI/UX

팀 노션 페이지

노션페이지 바로가기

와이어프레임 & 아키텍쳐

주요기능 🛠

🛠 그 외 라이브러리

• React-icons
• Redux logger
• React Devtools
• React Hook Form
• React Swiper
• React Multidate picker
• browser-image-compression
• Intersection Observer
• Sass

환경설정

- npm install --global yarn (yarn을 설치 안했을때)
- yarn install
- yarn start

❗ 핵심기능

Owner 와 Renter 간에 실시간 채팅, 알림 기능 💬

달력을 이용한 스케줄링 시스템 📅

검색을 이용해 주소 반경 20km안에 있는 차량 검색 기능 🔍

Owner 차량 월간/일간 수익지표 기능 🧮

📹 발표영상

영상보기

🕹️ 기술적 의사결정

사용기술	기술설명
Sock.js	실시간 데이터 통신으로서, 실시간으로 owner 와 renter가 채팅으로 정보 공유가 가능해졌다. 또한 실시간 알림을 통해 답장이 왔는지 알수 있게 되었다.
Redux-Toolkit	액션타입, 리듀서, 액션 생성 함수, 초기상태를 하나의 함수로 편하게 선언할 수 있고, 불변성 유지를 위해 번거롭게 코드들을 작성하지 않고 유지를 해준다.
Chart.js	사용자에게 수익을 한눈에 볼 수 있게끔 데이터를 시각화 하였다.
React-Multidate-Picker	오너의 편의성을 위해 등록날짜, 예약날짜를 구분하기 위함과 동시에 오너가 한 눈에 볼 수 있게 달력을 사용.
Kakao Map API & Daum Postcode API	두 가지 API를 같이 사용한 이유는 우선 kako map api 성능은 google map 다음으로 빠르다. google map은 대한미국에서 사용하기에 적잘하지 않기 때문에 kakao map 을 사용했고, daum postcode api는 카카오 맵과 호환성이 뛰어나고, 우리 서비스상 필요한 상세주소가 다 담겨져 있어서 사용하기 편했다.
Intersection Observer	scroll-height로 계산하여 무한스크롤 사용이 가능하지만, Intersection Observer 를 사용하면 이미 설정한 element가 노출이 되었는지 판단하고 감지가 되어서 이 점을 활용하여 무한스크롤을 구현했다. 불필요한 요청을 줄이고 필요할때만 요청이 가게끔 했다. 그리고 debounce & throttle 같이 추가적으로 코드를 안써도 되고, offsetTop으로 layout에 정확한 값을 구하기 위해 Reflow를 하는데, Intersection Observer를 사용하면 매번 Reflow를 할 필요없다.
browser-image-compression	이용자들이 고의적으로 많은 양에 고화질 이미지들을 업로드 했을때 s3 비용과 서비스 렌더링 속도에 악 영향을 미칠수 있기에, 프론트쪽에서 이미지 용량을 압축해서 s3로 보내기 위해서 도입 하였습니다.

🔎 Trouble Shooting

이미지 렌더링 속도 최적화

Intersection Observer

목적: 방대한 양에 데이터들을 나눠서 요청하기 위함

문제사항: 등록된 차들이 많아지면서 렌더링 되어야하는 데이터들이 많아짐, 하여 페이지 로딩 속도가 저하됨

해결방안:

1. Intersection Observer API으로 무한스크롤 구현
2. 순수 JS 로 scroll height로 계산하여 무한스크롤 구현

의견 조율: Intersection Observer 이용하면 호출 수 제한 방법인 debouncem throttle을 사용하지 않아도 되고, reflow를 하지 않아도 됩니다.

의견 결정: scroll height으로 가능하나 페이지마다 layout height 을 다시 설정해야되고, debounce 나 throttle을 따로 사용해야함, 하여 intersection observer 내의 변화를 비동기적으로 관찰하여 스크롤시 지정된 수 만큼 데이터가 요청되고 렌더링이 됨

부가설명: Intersection Observer 도입 후, db에 있는 모든 이미지들을 한번에 불러오는게 아니라 서버와 합을 맞춘대로 20장을 먼저 로딩하고, 미리 타겟으로 지정해둔 요소가 화면에 보일때 다음 20장 이미지를 로딩하게끔 설정하였다. 이렇게하면 모든 이미지를 한번에 요청할 필요없이 첫 20장만 먼저 렌더링이 되기 때문에 로딩 시간을 단축하였다. (영상참조)

Intersection Observer 영상

Lazy Loading

Lazy Loading 사용하여 화면에 나타나는 이미지 순으로 렌더링이 되게끔 설정하였습니다. 사용자가 스크롤을 내림으로서 보여지기 시작하는 이미지들이 렌더링이 되기 시작함. 밑에 사진과 (영상 참고).

Lazy Loading 영상

이미지 용량 최적화

도입이유: 고화질 이미지 렌더링 속도 개선

문제상황: 큰 용량 때문에 S3 비용과 클라이언트 이미지 렌더링 속도 저하

해결방안: FE: browser-image-compression 패키지 사용BE: imgscalr를 활용한 imageResize

의견결정: maxSize MB를 1로 지정, (그 이하는 이미지 깨짐 현상 발견)

Base 64

Decoding

Backend 내부에서 image resize한 후 S3 업로드

imgSclr를 활용한 이미지 리사이즈

원본이미지 정보

원본이미지 업로드 후 (사이즈: 326KB)

압축 후 이미지 정보 (사이즈: 198KB)

resize 전 이미지 정보 (Dimension: 1024x683px)

resize 후 이미지 정보 (Dimension: 800x534px / rezie을 인해 용량도 한번 더 축소가 되었음 => 54.9KB)

압축&resize 적용 전 걸리는 로딩시간

압축&resize 적용 후 걸리는 로딩시간

성능향상 수치 정리

---	Size	Dimensions	렌더링 속도
원본이미지	325KB	1024*683	77.8ms
프론트 압축	198KB	1024*683
백엔드 Resize	54.9KB	800*534	30.1ms
최종 감소율	83.16% 감소	----	61.3% 감소

Lighthouse 성능결과 => LightHouse 성능 결과 69점 → 80점