예술문화를 사랑하는 모든분들을 위한!
위치기반 문화컨텐츠 추천 어플리케이션!
| 이름 | 깃허브 주소 | 포지션 |
|---|---|---|
| 서지운 | MildColor의 github | Frontend |
| 임소희 | Limsoheeee의 github | Frontend |
| 국경훈 | kyunghoonkook의 github | Frontend |
| 장지윤 | Jaylin의 github | Backend |
| 김지애 | kimjiae970의 github | Backend |
| 박현도 | atto08의 github | Backend |
기간 : 2023년 01월 02일 ~ 2022년 02월 10일(5주)
API
| 스택 | 도입 이유 | 버전 |
|---|---|---|
| Expo | 1. 요구사항 및 문제: App을 만들기 위해 초기 개발환경 설정이 필요. 2. 대안 : expo CLI, react-native CLI 3. 의사결정 : 이번 side project는 react-native를 이용한 어플리케이션을 만드는 경험과 빠른 개발 속도를 추구 하였음. 때문에 초기 개발환경 설정의 번거로움을 줄여주고 배포를 빠르게 할 수 있는 expo를 선택. 또한 어플리케이션이 요구하는 기능들은 expo에서 제공해주는 sdk만으로 구현하기에 충분했기 때문에, 커스텀 네이티브 모듈 개발등 다른 언어로 추가 개발할 이유가 없다고 생각. |
^47.0.13 |
| React-Native | 1. 요구사항 및 문제: App을 만들기 위한 프레임워크의 도입이 필요 2. 대안 : react-native, flutter, kotlin 3. 의사결정 : ios와 android, 즉 하이브리드 앱 개발이 가능하고 이미 React를 다루는 프론트엔드 측에서 dart나 java등 새로운 언어를 배울 필요 없이 빠른 개발 속도를 기대할 수 있는 react-native를 도입하기로 결정 |
0.70.5 |
| React-Query | 1. 요구사항 및 문제: 기존에 비동기 데이터 처리를 위한 redux thunk 를 사용할 경우, redux의 기본원칙을 충족하기 위해서는 보일러 플레이트 코드가 방대해지고, 서버데이터와 클라이언트 데이터가 섞여서 데이터를 관리하는데에 문제 발생. ⇒ 서버데이터와 클라이언트의 데이터를 분리시켜 관리하고, 유연한 작업을 위한 라이브러리의 도입이 필요. 2. 대안 : 1) redux saga 2) redux-thunk 4)react-query 3. 의사결정 : - redux saga: 상대적으로 높은 learning curve ⇒ 단기 프로젝트에서 부적합 - redux thunk ⇒ redux 설정이 서드파티로 인해 더욱 비대해고, 비동기 데이터를 관리하기 위해 관련된 코드를 개발자가 결정하고 구현해야한다. 협업시에 복잡해지고, 개발 시간에서도 단점으로 작용. - react query ⇒ 보일러플레이트 코드의 감소, react-query에서 제공하는 규격화된 상태관리 방식은 협업과 코드작성시 효율적, 지속적으로 서버의 상태를 불러오고, 캐싱하기 때문에 비동기 데이터를 관리하기에 용이. 개발 속도와 편리성을 위해 react query 채택 |
^4.22.0 |
| jotai | 1. 요구사항 및 문제: prop drilling을 피하기 위함과 전역적으로 데이터들을 관리해주는 상태관리 라이브러리 도입 필요성을 느낌 2. 대안 : redux, recoli, mobx, context api, zustand, jotai 3. 의사결정 : 서버에서 비동기로 받아오는 데이터는 React Query로 담당하기로 하였고, 앱 내에서만 사용하는 데이터들을 관리하는 라이브러리가 필요하다 판단. 대부분의 비동기 데이터로 React Query로 다루기 때문에 전역적으로 관리할 데이터가 매우 적음. 따라서 보일러 플레이트가 적고 러닝커브가 낮은 라이브러리를 선택. ㅁatomic state management 방식의 라이브러리인 recoil과 jotai중 도입이 덜 어려운 jotai로 결정함. |
^2.0.0 |
| Axios | 1. 요구사항 및 문제: 백엔드와 데이터 비동기 통신을 하기 위한 라이브러리 도입 필요.편의를 위한 기능과 브라우저 지원과 같은 확장성 고려. 2. 대안 : AXIOS, FETCH, AJAX 3.의사결정: - FETCH : 별도의 설치과정이 불필요하지만, 응답데이터를 JSON메소드를 통한 변환 과정이 필요, 브라우저 지원범위는 AXIOS 보다 적음. -AJAX : jquery 를 통해 쉽게 구현가능, Error, Success, Complete의 상태를 통해 흐름을 구분 가능, 그러나 promise기반이 아님. -AXIOS : 설치과정이 필요하지만, 더 넓은 브라우저 지원범위, 응답데이터를 자동으로 JSON으로 변환, 별도의 인스턴스 생성가능으로 인한 유지보수, 가독성 면에서 장점, interceptor 기능 제공 ⇒ jquery는 프로젝트에 도입하지 않고, Fetch와 AJAX 보다 더 많은 편의 기능을 제공하는 AXIOS를 도입. |
^1.2.2 |
작성 예정
| 페이지 | API 연결, 기능 및 CSS |
|---|---|
| 로그인, 회원가입 - 서지운,국경훈 | ✅카카오 로그인 |
| 메인페이지 - 임소희 | ✅ 사용자 위치정보 수집 및 권한 관리 ✅ 위치기반 컨텐츠 추천 ✅ 메인 홍보 카루셀 ✅ 베스트, 신규 글 |
| 카테고리 - 서지운 | ✅카테고리별 컨텐츠 뷰 ✅ 카테고리 드롭다운 |
| 컨텐츠 상세페이지 - 서지운 | ✅ 화면 가로 넓이에 맞게 이미지 포스터 크기 대응 ✅ 포스터 카루셀 |
| 커뮤니티 - 서지운 | ✅커뮤니티 CRUD ✅카테고리 ✅상단TOP 버튼 ✅갤러리 이미지 불러오기 |
| 검색페이지- 임소희 | ✅검색결과 리스트 뷰 ✅추천 검색어 기능 |
| 공지페이지 - 임소희 | ✅ 공지 관련 CRUD |
| 마이페이지(메인) - 국경훈, 임소희 | ✅마이페이지 CRUD |
| 마이페이지(글목록, 티켓목록, 좋아요 리스트 ) - 임소희 | ✅마이페이지 CRUD |
| 마이페이지(티켓기록하기) - 서지운 | ✅ 티켓기록하기 기능 ✅ 해당 컨텐츠 검색 |
| 페이지 | API 기능 개발 |
|---|---|
| 로그인, 회원가입 - 장지윤 | ✅ 카카오 로그인(OAuth) |
| 메인페이지 - 장지윤, 김지애 | ✅ 사용자 위치정보 기반 컨텐츠 추천 기능 ✅ 베스트, 신규 글 |
| 카테고리 - 박현도 | ✅ 카테고리별 컨텐츠 모아보는 기능 |
| 컨텐츠 상세페이지 - 박현도 | ✅ 컨텐츠 상세페이지 정보보는 기능 |
| 커뮤니티 - 박현도 | ✅ 커뮤니티 CRUD |
| 검색페이지- 박현도 | ✅ 통합 검색 기능 |
| 공지페이지 - 박현도, 장지윤 | ✅ 공지 관련 CRUD ✅ 관리자 권한 추가 |
| 마이페이지(메인) - 장지윤 | ✅ 마이페이지 CRUD |
| 마이페이지(글목록, 티켓목록, 좋아요 리스트 ) - 장지윤 | ✅ 마이페이지 CRUD |
| 마이페이지(티켓기록하기) - 장지윤 | ✅ 티켓기록하기 기능(S3 연동) |
Infinite Carousel
| 구분 | 설명 |
|---|---|
| 문제 상황 |
|
| 문제원인 | |
| 문제해결 | |
| 해결결과 |
Front-end
- 과거 채팅 무한 스크롤로 불러오기
- 커뮤니티 댓글 기능
- 검색, 좋아요등 서버에 부하가 올 수 있는 api call 최적화
- 이미지 용량 최적화
- 채팅에서 이미지 전송 기능 추가