부트캠프 1차 프로젝트가 종료되었다. (4/16 ~ 4/30)
총 2주동안 진행되었으며 내가 맡은 분야는 프론트엔드였다.
사용 기술스택은 FE-Vanilla Js, BE- Node.js, MongoDB
이며 자세한 사항은 밑에 적어 놓았다!
온라인 서점 [ Eladin ]
프로젝트 주제
- 목적 : 필요한 책들을 찾아보고 간편하게 구매할 수 있게 하는 유저 서비스를 제공합니다.
- 목표
- 홈에서 엘라딘 베스트 셀러, 추천 도서 등 유저에게 유용한 서비스를 제공합니다.
- 회원 가입을 하지 않아도 마이페이지를 제외한 모든 기능을 이용할 수 있습니다.
- 상품 조회부터 구매까지 짧은 프로세스로 유저가 빠져들게 합니다.
페르소나
💡 John Doe (존 도씨, 오타쿠) : "책을 사고 싶어요. 근데 나가기가 너무 귀찮은걸요?"
서비스 소개
상품 등록, 장바구니 추가, 주문하기 등 쇼핑몰의 핵심 서비스를 구현합니다.
- 회원가입, 로그인, 회원정보 수정 등 유저 정보 관련 CRUD
- 상품 목록을 조회, 상품 상세 정보를 조회 가능함.
- 상품 목록, 상세 페이지, 장바구니 어디서든 주문 페이지 로 연결하여 구매가 가능함.
- 장바구니에서 주문, 바로 결제 버튼으로 주문 완료 후 회원만 마이페이지에서 조회 및 삭제가 가능함.
- 장바구니는 서버 DB가 아닌, 프론트 단에서 저장 및 관리됨 (indexedDB).
- 회원, 비회원, 게스트 유저 모두 원하는 키워드를 검색하여 상품 조회가 가능함.
데모 사이트
API 설계 문서
기술 스택
Infra
🚀 구성원 역할
이름 | 담당 |
---|
:dog: 안동현 | FE (팀장) |
:tiger: 박지원 | BE |
:cat: 권성경 | FE |
:mouse: 박정민 | FE |
:dolphin: 김희산 | BE |
프론트엔드
- Vanilla Javascript, HTML, CSS
- Font-Awesome
- Goole-fonts
- animate.css
- swiper.js
- 카카오(다음) 주소 API
역할
- :dog: 안동현
- 페이지 레이아웃, 회원가입 유효성 검사, 로그인, 검색 기능, aws ec2를 이용한 재배포 등
- :cat: 권성경
- 페이지 레이아웃, 모달 창, DAUM 주소 api, 회원가입 유효성 검사 등
- :mouse: 박정민
- 페이지 레이아웃, 장바구니(Indexed DB) 등
백엔드
- Nodejs + Express
- dotenv,cookie-parser,cors
- jsonwebtoken,uuid
- bcrypt
- mongoose
- multer
역할
- :tiger: 박지원
- Dummy Data 수집 -kakao 도서검색 API 구현
- 유저,상품,주문 스키마 작성 및 모델 구현
- 로그인 중복 검사 API 구현
- 비회원 인증 API 구현
- 상품,주문 API구현
- 비회원 uuid 유효성 검사 미들웨어 구현
- :dolphin: 김희산
- 서버 구축 및 데이터베이스 연결(mongoDB)
- 회원가입,로그인 API 구현
- JWT 유효성검사 미들웨어 구현
- 이미지 업로드 미들웨어 구현
- VM 배포,Nginx 라우팅,도메인 연결
- Notion : 수정이 빈번하고 같이 수정해야하는 것, API 명세
- Discord : 화상회의 , 수시로 스크럼 잡는 용도
- Gitlab : Code Repository
- Gitlab Issue : 진행상황이나 Trouble Shooting 내역 적기
- Postman Teams : API 테스트 진행
코드 컨벤션
- CSS 클래스명은
-
으로 표시
- 파일명이 여러 단어로 이루어지면 ‘- (하이픈)’ 으로 연결하기
- 변수명 Camel Case
- 함수명 동사로시작
- Prettier 라이브러리 적용
- dotenv 라이브러리로 환경변수 관리 및 사용
- 객체지향,함수형 프로그래밍 패러다임
Commit 컨벤션
- create: 파일 생성
- feat: 새로운 기능
- fix: 수정 사항
- style : 주석 제거 등 기존 코드에 영향이 없을 때.
- delete: 파일 삭제
배포
=> 부트캠프
- GCP에서 VM 인스턴스를 생성
- Nginx를 설치하고, 설정하여 웹 서버로 활용
- Gabia Domain, Google Domain을 구입하여, DNS 설정을 통해 도메인과 VM 인스턴스를 연결
- Let's Encrypt에서 무료 SSL 인증서를 발급받아 Nginx 웹 서버에 적용하여 HTTPS 프로토콜을 지원하도록 설정
=> 개인
- AWS에서 ec2 인스턴스 생성
- Nginx 설치 및 pm2 설치
- DNS 설정을 통해 도메인과 ec2 인스턴스 연결
실행 방법
git clone {.....repository_name}.git
cd {repository_name}}
npm install
npm run start
.env 설정
BCRYPT_SALT_ROUNDS={BCRYPT_SALT_ROUNDS}
PORT={PORT}
DB_HOST={DB_HOST}
DB_NAME={DB_NAME}
ACCESS_TOKEN_SECRET={ACCESS_TOKEN_SECRET}
REFRESH_TOKEN_SECRET={REFRESH_TOKEN_SECRET}
REFRESH_TOKEN_EXPIRES_IN={REFRESH_TOKEN_EXPIRES_IN}
ACCESS_TOKEN_EXPIRES_IN={ACCESS_TOKEN_EXPIRES_IN}
Copyright
Copyright © Eladin All Rights Reserved
회고
- Git을 이용하여 팀원들과 협업이란 것을 제대로 해 보았던 프로젝트 였다. 여러가지 Git 명령어에 대해 자세히 알게 되었고 merge Conflict 해결도 전보다 능숙해진 것 같다. 백엔드 파트 팀원들과 의견이 항상 같은 방향은 아니였어서 충돌은 있었지만 이로 인해
팀원과의 소통
이라는 능력과 멘탈을 더욱 더 강하게 키울 수 있는 계기가 되었다.
피드백
- 기존 로그인 및 회원 정보 수정 로직 중 유효성 검사를 클라이언트 단에서 정규식으로 진행하고 후에 정규식 조건이 충족될 시, 유저가 타이핑 하는 순간 마다 서버로 부터 api 요청을 보내 사용자 DB와 대조하여 중복체크를 하는 방향으로 코드를 짰었다.
-
이 부분에 관하여 받은 피드백은 "쓰로틀링
과 디바운싱
이라는 개념을 적용했다면 더 좋았을 것 같다." 라는 피드백이였다. 잘 몰랐던 개념이라 발표가 끝난 후 간단하게 찾아보았었다.
-
텀이 짧은 지속적인 api 요청을 서버로 보낼 경우, 서버의 부하가 걸릴 수 있는데, 쓰로틀링이나 디바운싱 로직을 적용하여 로직을 짜면 서버 부하 위험을 줄일 수 있다고 한다. 후에 더 자세하게 알아보고 정리하고, 코드 리팩토링을 진행할 예정이다! 😀
알게 된 점
- 민감한 정보는 .env 파일을 활용하자!
- 백엔드 부분에서 .env 파일에 보안에 민감한 정보를 담아 놓고 사용하는 것을 보았다. 다음 2차 리액트 프로젝트에서는 .env 파일을 활용하여 민감한 정보는 은닉하여 프로젝트를 진행해 볼 예정이다! 😇
- 각종 컨벤션
- 협업 시에는 컨벤션이 참 중요하다는 것을 알게 되었다. 프로젝트를 기획하고 개발하기에 앞서 git commit 컨벤션, css 컨벤션, 변수 네이밍 컨벤션, prettier 등 다양한 컨벤션을 정하고 시작하니 서로의 코드를 보다 읽기 편하였고, 다른 팀원이 어떤 작업을 하여 push를 했는지 알아볼 수 있어 좋았다. 팀 프로젝트에 있어서 컨벤션은 중요하다고 느꼈다.
- 데이터의 흐름
- 프론트와 백엔드 사이의 데이터 흐름을 알게 되었다. 또 백엔드 단에서 jwt 인증 방식으로 로그인을 구현하였기 때문에, 클라이언트 단에서 어떻게 api 요청을 보내야 하는지, 쿠키는 어떻게 웹사이트에 등록되고 서버로 이동하는 지를 알 수 있었다.
localStorage
라는 것도 처음 사용해봤으며, 더 나아가 indexedDB로 타 팀원 분이 장바구니를 구현했었는데 웹 브라우저의 저장소에 대해 더 자세히 알 수 있었던 계기가 되었다.
- (번외) node.js의 api 함수 위치
백엔드 코드에서 밑과 같은 라우팅 경로의 api 함수들이 있었다.
router.get('/:orderNumber');
router.get('/user/:userId');
- 처음에 api 요청을 보낼 때 나는
/user/:userId
라는 경로로 파라미터와 함께 GET
요청을 보냈었다. 그러나 서버에서 던진 것은 response 데이터가 아니라 에러... 경로도 맞고 메소드도 맞고 header도 올바르게 해서 보냈는데 왜 안될까.. 대체.. 의문을 가지며 팀원들과 거의 하루를 디버깅했다.
결과
에러도 의도하지 않은 api 함수의 에러 메시지가 던져졌다.
결론은 api 함수 순서 문제였다. 위의 /:orderNumber
의 GET 요청을 처리하는 api 함수에 /user/:userId
로 보낸 클라이언트 단의 api 요청의 url이 파라미터로 한꺼번에 들어간 것이다. 정말 큰 것을 배운 느낌이였다.
느낀 점
- 2주 라는 시간이 부족하다는 것을 알기에 다들 열심히 밤새며 참여했기에 좋은 결과물이 나와서 뿌듯하였다. 비록, 코드를 짜고 협업을 하는 과정에서 여러가지 에러도 많이 직면하고 백엔드 쪽에서 데이터가 이상하게 넘어오는 등 여러가지 갈등상황이 있었지만, 이를 팀원과 조율하고 극복하는 과정과 더불어 내가 짠 코드가 정상적으로 작동하는 것을 보면 정말 개발은 재밌는 것 같다..