독서가 부족한 현대인들을 위해! 갓생을 살고싶은 현대인들을 위해!
새로운 사람들과 즐겁게 얘기하며 독서 할 수 있는 웹 어플리케이션
| 이름 | 깃허브 주소 | 포지션 |
|---|---|---|
| 서지운 | 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
| 스택 | 도입 이유 | 버전 |
|---|---|---|
| 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 |
| 페이지 | API 연결, 기능 및 CSS |
|---|---|
| 로그인 - 서지운 | ✅카카오 로그인 ✅로그인 ✅아이디 찾기 ✅비밀번호 |
| 회원가입 - 서지운 | ✅회원가입 ✅아이디 중복 체크 ✅닉네임 중복 체크 |
| 마이 페이지 - 서지운 | ✅로그아웃 ✅문의하기 ✅개인정보 수정 ✅Pagination |
| 메인페이지 - 국경훈 | ✅배너 ✅카테고리 ✅인기모임 ✅상단TOP 버튼 ✅채팅 버튼 ✅ 후기 3개 최신 불러오기 |
| 모임 전체 페이지 - 국경훈 | ✅카테고리 별 sort |
| 모임 상세 페이지 - 국경훈 | ✅등록된 모임 정보 불러오기 |
| 모임 관심 - 국경훈 | ✅관심 모임 등록 |
| 모임 참석/탈퇴 - 국경훈 | ✅모임 가입하기 탈퇴하기 |
| 모임 작성 페이지 - 조재신 | ✅모임 작성하기, 네이버 책 검색, Pagination |
| 모임 수정 페이지 - 조재신 | ✅모임 수정하기, 네이버 책 검색, Pagination |
| 모임 삭제 기능 - 서지운 | ✅모임 삭제하기 |
| 채팅 - 조재신 | ✅ SockJS, Stomp를 이용한 채팅 구현(채팅, 방 만들기) |
| 검색 기능 - 조재신 | ✅ 네이버 책 검색, Pagination |
| 모달 - 서지운 | ✅모달 css |
| 후기 - 국경훈 | ✅후기 생성,삭제,불러오기 |
| 헤더 - 서지운 & 국경훈 | ✅헤더 css ✅헤더 검색 |
| 푸터 - 국경훈 | ✅푸터 css |
| 반응형 - 전체 | ✅모바일 ✅PC |
| 구분 | 설명 |
|---|---|
| 문제상황 | 채팅방의 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
| 구분 | 설명 |
|---|---|
| 문제 상황 |
맨 끝 배너에서 첫 번째 배너로 넘어갈 때 자연스럽게 넘어가지 않고 역재생 되는 듯한 애니메이션 발생 |
| 문제원인 | transition + 양 끝 이미지에 추가적인 이미지가 없기 때문에 처음으로 돌아감 때문에 역재생 애니메이션 발생 |
| 문제해결 | 배너 양 끝에 데이터를 복사해 주고 끝 배너에서 첫 번째 배너로 넘어갈 때 transition을 없애줌 |
| 해결결과 | 해당 하는 이미지의 개수만큼 배너 이벤트가 이루어 지기 때문에 자연스럽게 넘어가는 애니메이션이 생김 |
c.mp4
_2022_12_10_23_52_01_642.mp4
인원 다 찼을때 post요청에 대한 response를 error로 보내주셨는데 해당 response를 data로 잡고 있었음 back에서 error -> data로 보내주심
프론트
서버로 input에 들어온 값을 보내기 전에 trim(’ ’)을 이용해 빈 값만 있는 경우를 걸러낸다
백엔드 개설시 받아오는 requestDto에 필수로 요구하는 입력값은 NotBlank 어노테이션을 달아놓아 필수로 요구하는 입력값은 입력하지 않으면 400에러가 발생하도록 변경
백엔드 개설시 받아오는 requestDto에 필수로 요구하는 입력값은 NotBlank 어노테이션을 달아놓아 필수로 요구하는 입력값은 입력하지 않으면 400에러가 발생하도록 변경
Front-end
- 반응형 도입 — 모바일ver --완료
- 보안 강화 — https -- 완료
- infinite carousel -- 완료
- infinite scroll — 모바일ver -- 완료
- 과거 채팅 무한 스크롤로 불러오기 -- 완료
- 후기 기능 -- 완료
- api instance -- 완료
- 검색, 좋아요등 서버에 부하가 올 수 있는 api call 최적화
- 이미지 용량 최적화
- 채팅에서 이미지 전송 기능 추가