Hanghae-Hot6

👉🏻 프로젝트 소개

독서가 부족한 현대인들을 위해! 갓생을 살고싶은 현대인들을 위해!
새로운 사람들과 즐겁게 얘기하며 독서 할 수 있는 웹 어플리케이션

ODOK 바로가기

Front-End Github

Back-End Github

Project Notion

👨‍👩‍👧 팀원 소개

이름	깃허브 주소	포지션
서지운	MildColor의 github	Frontend
조재신	1005jsc의 github	Frontend
국경훈	kyunghoonkook의 github	Frontend
류창민	ryucm의 github	Backend
조계일	chokyeil의 github	Backend
박현도	atto08의 github	Backend
장승주		DESIGNER

⚙️ 서비스 아키텍처

📅 프로젝트 기간

기간 : 2022년 11월 03일 ~ 2022년 12월 16일(6주)

🛠 프론트 기술 스택

🛠 백엔드 기술 스택

🗺 API 설계

API

✒ 와이어 프레임

Figma 보러가기

🔨 기술 도입 이유 - 라이브러리, 기술적 의사 결정 - 프론트엔드

스택	도입 이유	버전
TypeScript	1. 요구사항 및 문제 : 자바스크립트는 다이나믹 타입이기 때문에 코드 작성 동안에는 오류를 인지하지 못하다가 런타임 시 예기치 않은 곳에서 오류가 발생 할 수 있음. 또한, 자바스크립트에서는 데이터들의 타입을 명세하고 있지 않기 때문에 개발자가 데이터 사용 시 형태를 일일히 확인해야했음. 2. 대안 : 타입스크립트 3. 의사결정 : 프로젝트 데이터 흐름을 체계적으로 만들기 위해 타입스크립트 도입 사용되고 있는 데이터들의 타입을 명시해주어 협업하는 팀원들이 통일된 데이터 형식에 맞춰 작성함.	^4.4.2
Styled-components	1. 요구사항 및 문제: CSS의 컴포넌트 & JS연산의 필요성 느낌 2. 대안 : styled components, emotion 3. 의사 결정 : 유의미한 성능 차이가 있던 것이 아니므로 조금 더 익숙한 styled components 를 사용 하기로 함	^5.3.6
RTK	1. 요구사항 및 문제: 리액트로 앱을 제작할 시에 생겨나는 고질적인 문제인 prop drilling을 피하기 위해,앱 전역적으로 데이터들을 관리해주는 상태관리 라이브러리 도입 필요성을 느낌 2. 대안 : redux, recoli, mobx, context api, 3. 의사결정 : 서버에서 비동기로 받아오는 데이터는 React Query로 담당하기로 하였고, 앱 내에서만 사용하는 데이터들을 관리하는 라이브러리가 필요하다 판단. recoil, context api, mobx, redux 네가지 모두 위의 조건을 충족하는데 문제는 없다 . recoil은 사용법이 쉽고 직관적이라는 장점이 있지만 가끔 버그가 발견되었다는 다른 개발자들의 말을 들었다.(스스로 직접 겪어보지는 못하였음) mobx는 class 문법을 사용해야 하는데 팀원들은 class문법에 익숙하지 않아서 선택지에서 제외. context api를 사용하기 위해서는 팀원들끼리 컨벤션을 처음부터 정해줘야했다 이 과정에 많은 시간이 소모될 것 같아서 패스했다. 결국 프론트 팀원들 모두가 친숙한 redux를 사용하기로 함 . 많은 Redux 패턴들 중에서 Redux에서 공식적으로 사용하기를 권장하고 있는 Redux 패턴 방법인 Redux toolkit 사용하였다 Redux toolkit은 특히 typescript에 대한 연동이 잘 되어있고 공식 문서도 설명이 잘 되어있어 프로젝트에 적합한 상태 관리 툴이라고 판단.	^1.8.6
React-Query	1. 요구사항 및 문제: - 기존에 비동기 데이터 처리를 위한 redux thunk 를 사용할 경우, redux의 기본원칙을 충족하기 위해서는 보일러 플레이트 코드가 방대해지고, 서버데이터와 클라이언트 데이터가 섞여서 데이터를 관리하는데에 문제 발생. ⇒ 서버데이터와 클라이언트의 데이터를 분리시켜 관리하고, 유연한 작업을 위한 라이브러리의 도입이 필요. 2. 대안 : 1) redux saga 2) react async 3) redux-thunk 4) react-query 3. 의사결정 : - redux saga: 상대적으로 높은 learning curve ⇒ 단기 프로젝트에서 부적합 - react async: 적은 참고자료와 다운로드 수 ⇒ 현시점에서 도입하기에 부적합 - redux thunk ⇒ redux 설정이 서드파티로 인해 더욱 비대해고, 비동기 데이터를 관리하기 위해 관련된 코드를 개발자가 결정하고 구현해야한다. 협업시에 복잡해지고, 개발 시간에서도 단점으로 작용. - react query ⇒ 보일러플레이트 코드의 감소, react-query에서 제공하는 규격화된 상태관리 방식은 협업과 코드작성시 효율적, 지속적으로 서버의 상태를 불러오고, 캐싱하기 때문에 비동기 데이터를 관리하기에 용이. 개발 속도와 편리성을 위해 react query 채택	^3.39.2
Axios	1. 요구사항 및 문제: 백엔드와 데이터 비동기 통신을 하기 위한 라이브러리 도입 필요.편의를 위한 기능과 브라우저 지원과 같은 확장성 고려. 2. 대안 : AXIOS, FETCH, AJAX 3.의사결정: - FETCH : 별도의 설치과정이 불필요하지만, 응답데이터를 JSON메소드를 통한 변환 과정이 필요, 브라우저 지원범위는 AXIOS 보다 적음. -AJAX : jquery 를 통해 쉽게 구현가능, Error, Success, Complete의 상태를 통해 흐름을 구분 가능, 그러나 promise기반이 아님. -AXIOS : 설치과정이 필요하지만, 더 넓은 브라우저 지원범위, 응답데이터를 자동으로 JSON으로 변환, 별도의 인스턴스 생성가능으로 인한 유지보수, 가독성 면에서 장점, interceptor 기능 제공 ⇒ jquery는 프로젝트에 도입하지 않고, Fetch와 AJAX 보다 더 많은 편의 기능을 제공하는 AXIOS를 도입.	^1.1.3
Socket, StompJs	1. 요구사항 및 문제: 채팅 기능을 구현하기 위해서는 단방향적인 http통신을 쓰는 것은 서버, 프론트 둘 다에게 비효율적인 방식이기때문에 양방향 커뮤니케이션을 제공하는 웹소켓 프로토콜을 사용하기로 함. 웹소켓 프로토콜를 기반으로 만들어진 검증된 라이브러리를 사용하여 초기 세팅 리소스를 덜음. 2. 대안 : 웹소켓 프로토콜 : socket.io, ws, sockJs-client , 웹소켓 기능 API : stompJS 3. 의사결정 : 순수 웹소켓은 모든 클라이언트의 브라우저에서 WebSocket을 지원한다는 보장이 없다, 또는 서버가 순수 웹소켓 사용이 불가능할 경우가 있기 때문에 websocket 프로토콜을 제공하는 라이브러리를 사용하기로 함 websocket 프로토콜 라이브러리중 socket.io, ws는 노드에 최적화 되어있고, Spring 프레임워크는 Servlet 스택 위에서 Server/Client 용도의 SockJS 프로토콜을 모두 지원하기 때문에 SockJs를채택함 서버와 커넥트 되었을 때, 메세지를 보낼 때, 서버와 연결이 끊겼을 때와같은 채팅을 구현할 시 기본적으로 필요로하는 기능들이 잘 정리되어 들어있는 Stomp라이브러리의 도움을 받아 채팅 로직을 구현하기로 함	^6.1.2

🔨 기술 도입 이유 - 라이브러리, 기술적 의사 결정 - 백엔드

스택	도입 이유	버전
Node.js	메모리 사용과 관련하여 python, java 보다 효율적이며, jQuery를 통해 원하는 데이터를 추출하기에 용이하기 때문에 선택하였습니다.	^4.4.2
Redis	1) RefreshToken 저장, 2) email 인증 번호 유효 기간 설정	^5.3.6
docker-compose	각 사용자마다 개발환경이 다릅니다. 개별 환경마다 별도의 DB를 설치가 필요 => redis와 postgresql의 별도 설치 없이 동일 환경에서 test가 가능하도록 docker-compose를 구성	^3.39.2
CI-CD	JS 내장 기능이 아니기 때문에 import를 해줘야 하는 번거로움과 무거움이 다소 있지만 다음과 같은 편리한 기능 때문에 도입했다. JSON 데이터 자동 변환 / axios interceptor & 간결한 instance 기능	^1.1.3
WebSocket, Stomp	채팅 기능을 구현하기 위해서는 단방향적인 http통신을 쓰는 것보다 양방향적으로 통신을 가능하게하는 라이브러리가 필요로 했다. 여러가지 양방향 통신 라이브러리중, Spring 서버의 성격과 가장 잘 맞은 SockJs, Stomp라이브러리를 사용하였다	^6.1.2
spring email	회원가입 시 본인 인증 필요 아이디, 비밀번호 찾기	^4.4.2
OAuth2.0	회원 가입의 간편화를 통해 유저들의 사용 편리함 증가	^4.4.2
PostgreSQL	대용량 데이터 기반 서비스를 구축 하기 위해서. mysql의 버전 업그레이드를 통해 많이 성능이 향상되었지만, 그래도 postgresql이 join과 병렬 쿼리, MVC를 지원	^4.4.2
Amazon S3	이미지 저장. CICD의 과정	^4.4.2
Swagger fox	Back-end에서 구현이 끝난 것을 일일이 front-end에 전달하는 과정에서 delay 발생. 개발 도중 추가로 개발한 API를 매번 API명세서에 기입하는 과정이 어려워 swagger를 통해 간접적인 소통	^4.4.2

✨ 주요 기능 - 프론트엔드

페이지	API 연결, 기능 및 CSS
로그인 - 서지운	✅카카오 로그인 ✅로그인
회원가입 - 서지운	✅회원가입 ✅아이디 중복 체크 ✅닉네임 중복 체크
마이 페이지 - 서지운	✅로그아웃 ✅마이페이지 차트
메인페이지 - 국경훈	✅배너 ✅카테고리 ✅인기모임 ✅상단TOP 버튼 ✅채팅 버튼 ✅ 후기 3개 최신 불러오기
모임 전체 페이지 - 국경훈	✅카테고리 별 sort
모임 상세 페이지 - 국경훈	✅등록된 모임 정보 불러오기
모임 관심 - 국경훈	✅관심 모임 등록
모임 참석/탈퇴 - 국경훈	✅모임 가입하기 탈퇴하기
모임 작성 페이지 - 조재신	✅모임 작성하기, 네이버 책 검색, Pagination
모임 수정 페이지 - 조재신	✅모임 수정하기, 네이버 책 검색, Pagination
모임 삭제 기능 - 서지운	✅모임 삭제하기
채팅 - 조재신	✅ SockJS, Stomp를 이용한 채팅 구현(채팅, 방 만들기)
검색 기능 - 조재신	✅ 네이버 책 검색, Pagination
모달 - 서지운	✅모달 css
후기 - 국경훈	✅후기 생성,삭제,불러오기
헤더 - 서지운 & 국경훈	✅헤더 css ✅헤더 검색
푸터 - 국경훈	✅푸터 css
반응형 - 전체	✅모바일 ✅PC

✨ 주요 기능 - 백엔드

페이지	API 연결, 기능 및 CSS
로그인 - 류창민	✅카카오 로그인 ✅로그인
회원가입 - 류창민	✅회원가입 ✅아이디 중복 체크 ✅닉네임 중복 체크
마이 페이지 - 류창민	✅로그아웃 ✅마이페이지 차트
모임 CRUD - 박현도	✅
모임 전체 페이지 - 박현도	✅카테고리 별 sort
모임 상세 페이지 - 박현도	✅등록된 모임 정보 불러오기
모임 관심 - 박현도	✅관심 모임 등록
모임 참석/탈퇴 - 박현도	✅모임 가입하기 탈퇴하기
채팅 - 조계일,류창민	✅
검색 기능 - 조계일	✅

🎯 트러블 슈팅

채팅방 UI 개선

1. 채팅방 PC화면에서 모바일로 전환, 모바일화면에서 PC화면으로 전환시 더 부드러운 UX로 고치기

구분	설명
문제상황	채팅방의 PC화면(팝업화면)에서 모바일화면(풀화면)으로 전환 또 그 역순으로 전환할 때 채팅창이 닫혀짐 더 부드러운 UX로 개선할 필요가 있었음 더 부드러운 UX로 개선하기 위해서는 PC화면일때와 모바일화면일때의 채팅창을 보여주는 방식을 서로 다르게 가져가야 할 필요성을 느낌
문제원인	모바일 화면일때는 풀화면으로 보여주고 PC화면일 떄에는 팝업화면으로 보여주는 방법을 택함 풀화면으로 보여주기 위해서 ‘/mobile_chat’이라는 라우터를 따로 열어 줌 기존 코드는 채팅창을 열고 닫는 state가 한 컴포넌트에서만 접근이 가능했음 화면의 width를 실시간으로 판단하는 hook이 없어 어느 width에 모바일화면으로 접근하는지, PC화면으로 들어오는지 앱이 알수가 없었음
문제해결	채팅창을 열고 닫는 상태를 담는 redux의 slice를 새로 추가하고 상태관리를 전역적으로 바꿔줌 화면의 width를 실시간으로 판단하는 hook을 만듬 pc화면에서 모바일화면 상태로 돌입될 시 , 또 역순 일 시 hook이 작동이 되고, 이에 따라 이벤트가 발생되게끔 코드를 작성 이벤트의 콜백으로 PC화면 → 모바일 화면 일 경우, ‘/mobile_chat’으로 주소를 옮기고 모바일 화면 → PC화면 일 경우 채팅창 팝업을 띄우게 코드를 작성함
해결결과	유저는 채팅을 하는중에 갑작스럽게 화면 사이즈가 바뀌어도, 끊기지 않고 자연스럽게 채팅을 진행 할 수 있게 됨

적용 전

default.mp4

적용 후

default.mp4

Infinite Carousel

구분	설명
문제 상황	맨 끝 배너에서 첫 번째 배너로 넘어갈 때 자연스럽게 넘어가지 않고 역재생 되는 듯한 애니메이션 발생
문제원인	transition + 양 끝 이미지에 추가적인 이미지가 없기 때문에 처음으로 돌아감 때문에 역재생 애니메이션 발생
문제해결	배너 양 끝에 데이터를 복사해 주고 끝 배너에서 첫 번째 배너로 넘어갈 때 transition을 없애줌
해결결과	해당 하는 이미지의 개수만큼 배너 이벤트가 이루어 지기 때문에 자연스럽게 넘어가는 애니메이션이 생김

Infinite Carousel 적용 전/후

적용 전

c.mp4

적용 후

_2022_12_10_23_52_01_642.mp4

👩‍💻 유저 피드백 및 개선 사항

모임 참석 인원 다 찼을때 참석 하기 버튼을 누르면 null이 alert 으로 출력

인원 다 찼을때 post요청에 대한 response를 error로 보내주셨는데 해당 response를 data로 잡고 있었음 back에서 error -> data로 보내

클럽 썸네일 이미지가 null 이면 엑박이 뜬다.

프론트/백에서 썸네일이미지가 null 일때 디폴트 썸네일 넣어주어 썸네일 이미지를 넣지 않은 모임도 기본 이미지를 심어주었다.

비밀번호 수정 시 비밀번호 확인 일치해도 안 됨

임시 비밀번호를 수정 값으로 확인 하고 있어서 일치 확인이 불가 했었음

모임개설 할 때 스페이스바만 눌러서 모임개설이 됨

프론트 서버로 input에 들어온 값을 보내기 전에 trim(’ ’)을 이용해 빈 값만 있는 경우를 걸러낸다
백엔드 개설시 받아오는 requestDto에 필수로 요구하는 입력값은 NotBlank 어노테이션을 달아놓아 필수로 요구하는 입력값은 입력하지 않으면 400에러가 발생하도록 변경

모임개설시에 어떠한 값(인풋)이 입력되지 않았는지 판단하면 좋을 듯

input태그에 required 옵션을 달아주어서 form 제출 시 입력되지 않은 값을 명시하게 해줌

과거 채팅 infinite scroll로 가져오기

적용 완료

👻 추가하고 싶은 기능

Front-end

- 반응형 도입 — 모바일ver --완료
- 보안 강화 — https -- 완료
- infinite carousel -- 완료
- infinite scroll — 모바일ver -- 완료
- 과거 채팅 무한 스크롤로 불러오기 -- 완료
- 후기 기능 -- 완료
- api instance -- 완료
- 검색, 좋아요등 서버에 부하가 올 수 있는 api call 최적화
- 이미지 용량 최적화
- 채팅에서 이미지 전송 기능 추가

Back-end

- Redis를 연동하여 실시간 채팅 구현 고도화
- Node.js의 scheduler를 통해 크롤링의 자동화 진행 → AWS Batch - CloudWatch 사용 예정
- JPQL을 통해 성능 개선
- postgres를 이용한 full-text search 도입 (데이터가 많아질수록 Like를 사용한 검색은 속도가 느리며, 메모리에 부담을 준다)
- https 적용
- ECS를 통한 배포 --> 현재의 배포에는 EC2 서버에 직접 Redis, JDK, Code Deploy를 설치하고 있다. 이것은 docker-compose를 통해 간단 배포로 변경하고 싶습니다.
- ECR까지의 CI는 완료된 상태이나 ECS에서 Load Balace의 target group의 health check를 통과하지 못 하는 상태입니다.
- 시간이 남는다면 kafka를 크롤링 서버와 log 수집, 실시간 채팅에 도입한 Data Pipeline을 구축해 보고 싶습니다.
- Jwt 토큰 만료 예외처리 - JwtFilter 쪽에서

👉🏻 프로젝트 소개

ODOK 바로가기

Front-End Github

Back-End Github

Project Notion

👨‍👩‍👧 팀원 소개

⚙️ 서비스 아키텍처

📅 프로젝트 기간

🛠 프론트 기술 스택

🛠 백엔드 기술 스택

🗺 API 설계

✒ 와이어 프레임

Figma 보러가기

🔨 기술 도입 이유 - 라이브러리, 기술적 의사 결정 - 프론트엔드

🔨 기술 도입 이유 - 라이브러리, 기술적 의사 결정 - 백엔드

✨ 주요 기능 - 프론트엔드

✨ 주요 기능 - 백엔드

🎯 트러블 슈팅

1. 채팅방 PC화면에서 모바일로 전환, 모바일화면에서 PC화면으로 전환시 더 부드러운 UX로 고치기

적용 전

적용 후

Infinite Carousel

Infinite Carousel 적용 전/후

적용 전

적용 후

👩‍💻 유저 피드백 및 개선 사항

모임 참석 인원 다 찼을때 참석 하기 버튼을 누르면 null이 alert 으로 출력

클럽 썸네일 이미지가 null 이면 엑박이 뜬다.

비밀번호 수정 시 비밀번호 확인 일치해도 안 됨

모임개설 할 때 스페이스바만 눌러서 모임개설이 됨

모임개설시에 어떠한 값(인풋)이 입력되지 않았는지 판단하면 좋을 듯

과거 채팅 infinite scroll로 가져오기

👻 추가하고 싶은 기능

Pinned Loading

Repositories

People

Top languages

Most used topics