1. 기획
소셜 가계부 서비스의 기획 의도는 사용자들이 자신의 소비 습관을 관리하고, 다양한 방식으로 소비 관련 정보를 교류하며 소비 습관을 향상하는 데에 있습니다. 아래는 소셜 가계부 서비스가 제공하는 주요 기획 의도입니다.
- 개인 소비 관리:
- 사용자들은 개인 소비 내역을 간편하게 기록하고 분석하여 자신의 소비 습관을 파악하고 관리할 수 있습니다. 이를 통해 예산을 효과적으로 관리하고 불필요한 지출을 줄일 수 있습니다.
- 소비 정보 교류:
- 커뮤니티 기능을 통해 사용자들은 소비 관련 정보를 서로 공유하고 의견을 나눌 수 있습니다. 다양한 소비 팁, 할인 정보, 경험 등이 교환되어 사용자들이 더 현명한 소비 결정을 할 수 있습니다.
- 소비목표(예산) 설정:
- 소비목표(예산)를 설정하고 동료들과 경쟁하며 목표를 달성할 수 있습니다. 이는 사용자들에게 소비 습관 개선에 대한 동기부여를 제공합니다.
- 사회적 영향력 확장:
- 사용자들이 소비 내역을 공유하고 서로에게 영감을 주는 것은 사회적 영향력을 키울 수 있는 좋은 방법입니다. 또한, 사용자들이 지속적으로 서비스를 이용하면서 소셜 네트워크를 통해 다양한 사람들과 연결되고 소비 커뮤니티를 형성할 수 있습니다.
- 사용자 경험 강화:
- 간편하고 직관적인 사용자 인터페이스를 통해 사용자 경험을 강화하고, 사용자들이 손쉽게 서비스를 활용할 수 있도록 합니다.
2. 요구사항(구현 페이지) 정의
- 대시보드(메인): 예산, 수입/지출 내역, 소비분석 그래프 등을 개괄적으로 보여주는 대시보드 페이지
- 캘린더: 수입/지출 내역을 표시한 캘린더
- 가계부: 수입/지출 내역을 작성하는 페이지
- 챌린지: 목표 예산별 달성한 사람의 순위 표시 (가장 낮은 예산을 적용한 사람 중, 가장 소비를 덜 한 사람이 전체 1위 / 내가 지정한 예산별 순위 및 나의 순위, 각종 분류별 가장 높은 지출을 기록한 분류를 카드 형태로 보여주는 페이지)
- 커뮤니티: 제태크와 관련된 지식을 공유할 수 있는 커뮤니티 페이지(게시판 형식), 하단에 채팅
- 설정: 개인 프로필을 수정 및 조회할 수 있는 설정 페이지.
3. 기술 스택 선택
프론트엔드: React.js, Next.js
백엔드: Node.js, Express.js
데이터베이스: MongoDB
<기술 선택 이유>
- React.js:
- React.js는 사용자 인터페이스를 만들기 위한 선호도 높은 JavaScript 라이브러리입니다. 가상 DOM을 사용하여 성능을 최적화하고, 컴포넌트 기반 아키텍처를 통해 재사용성을 높일 수 있다는 장점을 가지고 있습니다. React.js는 단일 페이지 애플리케이션(SPA)을 구축할 때 특히 유용합니다.
- Next.js:
- Next.js는 React 기반의 서버 사이드 렌더링(SSR) 및 정적 사이트 생성(SSG)을 제공하는 프레임워크입니다. SEO 최적화, 성능 향상, 코드 스플리팅 등을 간편하게 적용할 수 있습니다. 또한, API 라우팅과 데이터 fetching을 지원하여 프론트엔드와 백엔드를 효과적으로 통합할 수 있습니다.
- 채용 공고 홈페이지를 보면서 Next.js가 실무에서 많이 사용되고 있다는 사실을 인지하고 실제 프로젝트에도 적용해 보고 싶어 사용하게 되었습니다.
- Node.js:
- Node.js는 JavaScript를 사용하여 서버 사이드 애플리케이션을 만들 수 있는 런타임 환경입니다. Non-blocking I/O와 높은 확장성을 제공하며, JavaScript를 사용하여 프론트엔드와 백엔드 양쪽에서 일관된 언어로 개발할 수 있습니다.
- Express.js:
- Express.js는 Node.js 웹 애플리케이션을 쉽게 구축할 수 있도록 도와주는 웹 프레임워크입니다. 미들웨어를 통한 요청과 응답의 처리, 라우팅, 에러 핸들링 등을 지원하여 간편하게 백엔드 로직을 구현할 수 있습니다.
- MongoDB:
- MongoDB는 NoSQL 데이터베이스로서 JSON 형식의 BSON 문서를 사용하여 데이터를 저장합니다. MongoDB는 확장성이 좋고, 유연한 데이터 모델을 제공하여 다양한 형태의 데이터를 저장할 수 있습니다. 특히, JSON과 유사한 문법을 사용하므로 JavaScript와 자연스럽게 통합됩니다.
4. 데이터 모델 계획(필요한 entity, 어떤 데이터를 프론트에서 백으로 넘길 건지...)★
--- Entity
Users (사용자)
- 속성: User_ID (고유 식별자), Name, E-mail, Password (암호화된 형태), Image (프로필 이미지)
- 관계: 가계부(입출금 내역, 목표 예산), 커뮤니티(작성자)
가계부 (Transactions)
- 속성: Transaction_ID (고유 식별자), User_ID (외래 키), Date, Transaction_Type (지출 또는 수입), Category, Title, Amount, Memo, 목표 예산
- 관계: 사용자 (User_ID 외래 키)
커뮤니티 (CommunityPosts)
- 속성: Post_ID (고유 식별자), Title, User_ID (외래 키), LastModifiedDate, Content
- 관계: 사용자 (User_ID 외래 키)
5. 백엔드 엔드포인트(API), 프론트 pages(SPA) 계획
--- API Endpoints
- 사용자 관리 (`/api/users/...`)
- [GET] `.../`: 사용자 정보 반환 (이름, 이메일, 프로필 이미지)
- [POST] `.../signup`: 신규 사용자 생성에 필요한 첨부 데이터를 받아 신규 사용자 생성+유저 로그인
- [POST] `.../login`: 유저 로그인(요청에는 이메일, 비밀번호가 첨부되어야 함)
- 가계부 관리 (`/api/transactions/...`)
- [GET] `.../user/:uid`: 특정 uid를 가진 사용자가 생성한 모든 수입/지출 내역 반환
- [GET] `.../:tid`: tid가 특정하는 수입/지출 내역 불러오기
- [POST] `.../`: 새로운 수입/지출 내역 생성
- [PATCH] `.../:tid`: pid를 따라가 해당 수입/지출 내역 수정
- [DELETE] `.../:tid`: pid에 해당하는 수입/지출 내역 삭제
- 커뮤니티 관리 (`/api/community/...`):
- [GET] `.../`: 모든 게시물 목록 반환
- [GET] `.../:cid`: 특정 게시물 반환
- [POST] `.../`: 새로운 게시물 생성
- [PATCH] `.../:cid`: 특정 게시물 수정
- [DELETE] `.../:cid`: 특정 게시물 삭제
- 유저 프로필 관리 (`/api/profile/...`):
- [GET] `.../`: 사용자 프로필 정보 반환
- [PATCH] `.../:uid`: 유저 프로필 정보 수정(이름, 패스워드)
- [DELETE] `.../:uid`: 유저 삭제(회원탈퇴)
--- SPA Pages
- `/`: 대시보드
- `/authenticate`: 회원가입, 로그인 폼
- `/calendar`: 캘린더
- `/transaction`: 유저 입출금 기록
- `/challenge`: 챌린지
- `/community`: 커뮤니티
- `/community/new`: 게시글을 추가하는 페이지로 연결
- `/community/:cid`: 게시글을 조회 및 수정하는 페이지로 연결
- `/profile`: 환경설정 및 개인 정보 페이지
<앞으로 진행할 과정들>
6. 프론트엔드 초안 구현
7. 백엔드 구현
8. 프론트엔드 구현
9. 테스트
10. 배포
11. 유지보수 및 업데이트
참고한 글들
기획 및 설계 참고
fe-be 전체적인 코드 흐름 살펴보기 · Yoonyesol/MERN_study@ad28fdc
Yoonyesol committed Sep 15, 2023
github.com
몽고 DB 설계
mongoDB Story 3: mongoDB 데이터 모델링 : NHN Cloud Meetup
mongoDB 데이터 모델링은 어플리케이션의 처리방안을 고려하여 도큐먼트를 적절한 방식으로 설계해야 합니다. 3부에서는 도큐먼트의 임베디드 방식과 레퍼런스 방식의 개념 및 데이터 모델링 절
meetup.nhncloud.com
MySQL만 써봤는데... MongoDB 프로젝트에 투입됐다🤯
빅데이터라는 시대의 요구에 맞추어 NoSQL이 등장한 지 십 년이 넘는 세월이 흘렀습니다. 하지만, 아직 RDB에 비해서 스키마 설계를 위한 참고 자료가 부족하다고 생각되는데요. 저 또한 MySQL만 사
dev.gmarket.com