개요
- 모델링 한 사이트 : 번개장터
- 나의 업무
- (공동) VVolt Market 기획
- (공동) DB 마이그레이션 파일 및 데이터 구축
- 상점 정보
- jwt로 불러온 본인 상점과 path파라미터로 불러온 상점의 정보 조회(GET)
- 하나의 엔드포인트로 개별 상점 정보(상점명, 이미지, 소개글) 수정(PUT)
- AWS S3 이미지 : single()로 상점 프로필 이미지 변경(PUT)
- 상품 정보
- 상품 정보 등록(POST) 영상 00:01:04
- AWS S3 이미지 : array()로 여러 상품 이미지 등록(POST)
- 찜
- jwt로 인증한 본인의 찜 개수 조회(GET)
- 하나의 버튼으로 찜 등록 및 해제 기능 (POST/DELETE)
- 팔로워 & 팔로잉
- jwt로 인증한 본인이 팔로잉 한 개수, 나를 팔로우한 수 조회(GET)
- 하나의 버튼으로 팔로우 등록 및 해제 기능 (POST/DELETE)
- 소개 영상 링크
https://www.youtube.com/watch?v=UDNfYsCpGR4 - 깃헙 레포
https://github.com/Gyelanjjim/39-2nd-VVolt-Market-backend - 구현 기간 : 2022.11.28(월) ~ 2022.12.09(금) (2주)
- 팀원 구성 :
BE김한솔, 박상욱, 송철진 /FE강지민, 심동섭, 정효원, 조은혜
잘한 점
-
회의록을 뒤늦게 작성했던 1차 프로젝트 때에 비해 2차 프로젝트는 첫날부터 꾸준히 회의록을 작성해서 프론트와 백엔드, 백엔드와 백엔드, 프론트와 프론트 간 소통이 쉬웠다.
-
다양한 협업툴로 소통에 적극적으로 참여했다
- 트렐로(Trello) : 1주일 단위로 스프린트를 관리하여 2주간 진행했다. 백엔드와 프론트엔드 간 소통하여 필요한 기능과 페이지를 기획했고 필요한 API를 큰틀에서 작은틀로 구분했다. 그리고 구현 난이도를 추정해서 팀원과 적절히 분담했다.
- DB ERD 다이어그램(db.diagram) : 테이블 간 기본키와 참조키의 관계를 정리하고, 전반적인 흐름을 공유했다.
- 노션(Notion) : 기능/API엔드포인트/담당자를 한눈에 알아볼 수 있게 표를 작성하고, 일일회의록(어제한일/오늘할일/어려운 점/질문할 점)을 작성하고 공유했다
- 깃북(GitBook) : 노션 API명세서의 단순 URI에 더해 상세한 명세를 작성했다; req.body, req.params, res.body, status code, 각각의 key 등 프론트엔드가 백엔드에 자주 물어보는 키값을 명료히 작성했다.
-
초반에 기획에 공을 들여 꼼꼼히 파악했다.
데일리 스탠드업 미팅때 노션에 질문하기 코너를 잘 활용해서 필요한 기능, 명칭, 단위를 수시로 점검하고 재확인했다. 스크린 샷, 그림판 활용 등 -
포기하지 않았다. AWS S3로 이미지 업로드 기능 구현하기가 어려워서 정 안되면 대안책으로 1차프로젝트 때처럼 img.bb에 올려서 링크 가져오는 방식을 고려했었지만, '이해한 부분, 실행했을 때 현상' 등 팀원과 blocker를 공유했고 여러 도움을 받아 결국 방법을 찾아냈다.
-
선택과 집중으로 생긴 자투리 시간에 프로젝트 완성도를 높이기 위해 서로 도왔다. API 구현과 유닛테스트 라는 두마리 토끼를 모두 잡을 수 있으면 물론 좋았겠지만 시간이 부족했다. 가장 중요한 API 구현만 하기로 선택하고 집중했고 남은 자투리 시간에는 팀원의 막힌 부분에 대해 방안을 찾아내기도 했고 다른 API를 대신 맡아 구현하기도 했다.
🎈 이슈1. (카카오로그인 관련) 50회 가량 테스트했는데 카카오 서버로부터 받은 social_id가 DB테이블에 insert될 때도 있고 안될 때도 있었다.
👉 코드 동작방식에 대한 설명을 듣고 조건문에await가 들어가면 어떨까? 라고 제안하여 실행했더니 잘 동작했다.
🎈 이슈2. D-1, 팀원 모두 밤샘 작업으로 지친 상황, 아직 follow 등록/해제 API이 구현되지 않았다는 것을 뒤늦게 알아차렸을 때
👉 코드카타의 Driver와 Navigator 처럼 Navi역할을 맡아 그 API를 구현할 수 있었다.
아쉬운 점
2차프로젝트 기간에도 커리큘럼 상 학습하고 활용할 몇몇이 있었는데 모두 적용했으면 좋았겠지만 기본 API구현과 프론트엔드-백엔드 간 합을 맞춰보는데에 시간을 더 쏟아 몇몇 기술들을 100% 활용하진 못한 점이 아쉽다. 유닛테스트, docker로 배포하기 등 추후 시간을 내서 코드를 리팩토링하고 꼭 다시 해볼 예정이다.
내가 구현하고 postman으로 테스트까지 마친 API 중 하나(상품 정보 Update)가 최종 기획에 포함되지 않아 아쉬운 점도 있었다. 모든 것이 처음 잘 계획한 그대로 가면 좋겠지만 어찌보면 당연하게도 하나의 서비스가 완성되기 까지 모두에게 합리적인 방향으로 일이 진행될 수 밖에 없을 것이다.
AWS S3를 활용한 상품정보(이미지) 등록 API, 상점 프로필 이미지 변경 API를 구현하는 것은 학원에서 교육받고 읽기 쉽게 정제된 학습자료를 넘어서 직접 자료를 검색하고 방대한 데이터에서 원하는 정보를 뽑아 활용하기 위한 나의 첫 과제였다. 처리 속도 관점에서는 비교적 빨리 구현할 수 있는 CRUD API를 먼저 끝내놓고, S3 이미지 업로드 과정을 탐색했던 내 방식이 좋았을지도 모른다. 하지만 중요도 관점에서 다른 팀원들은 카카오로그인, 토스 결제 등 외부 API라는 핵심 기술을 스프린트 초기부터 중점적으로 탐색했던 것과 비교했을 때 아쉬운 자세였다. 앞으로도 제한된 기간에 기존 기술과 새로운 기술을 활용해야하는 과업이 주어졌을 때, 주어진 시간을 중요도, 난이도, 긴급도에 따라 어떻게 분배해서 작업을 수행할지 다시 생각해볼 좋은 계기가 된 거 같다.
어려웠던 점
- AWS S3 업로드 기능 검증
-
이슈: 프론트엔드의 도움을 받아 S3 버킷으로 파일을 전송했을 때 다음과 같은 로그를 확인했다.
- F/E:
404 Error, PATCH, /users, B/E:400 Error, GET, /users
무언가 fetch가 잘 안된걸수도 있고.. 여러 복합적인 무언가가.. status code만 보고서 리누스 토발즈가 와도 무슨 문제인지 알 수 없다라는 멘토님의 답변을 들었고, 그럼 프론트엔드와 백엔드 간 통신 중 발생할 수 있는 에러를 제외하고 오직 파일 업로드에 대한 에러만 확인하려면 어떻게 해야할까? 즉, 백엔드 코드로만 파일 업로드 여부를 확인하려면 어떻게 해야하는가?
- F/E:
-
해결: POSTMAN으로 formData file 전송할 수 있다!
참조 링크: https://tape22.tistory.com/9
- AWS S3 타입 에러
현상:TypeError: this.client.send is not a function
해결: package.json 에서 설치버전이 2.x 로 동일해야 한다
"multer-s3": "^2.10.0"
"aws-sdk": "^2.1269.0"
참조 링크: https://tape22.tistory.com/9
- AWS S3 액세스 거부
현상: (postman으로 form data 전송 시)message : access denied
해결: S3 버킷 정책 설정 필요!
{
"Version": "2012-10-17",
"Statement": [
{ "Sid": "PublicListGet",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::버킷이름",
"arn:aws:s3:::버킷이름/\*"
]
}
]
}
