이번 주차에는 첫 FE - BE 협업을 도전했습니다.
[BE]
- 에러 로거 적용
- 도커 이미지 파일 만들어서 repo에 푸쉬까지 했지만, 최종 서버에는 도커 파일로 배포하지 못했음
- https로 서버 열기(사실상 동석님이 해주심
[FE]
- aws R3 이미지 서버를 프런트에서 만들고 관리함
트러블 슈팅
[트러블 슈팅보다는 헤프닝...]
기존에 잘 작동하던 api서버가 업데이트 이후 이상해졌다!! 게시글을 포스팅하면, 내 아이디가 아닌 test1이라는 동일한 아이디로 포스팅이 된다!!(두둥) 무슨 문제인지 알아보기 위해, 백엔드 서버 사용자 인증 미들웨어에 토큰 값을 콘솔로 찍어보았다. 프런트에서 req.headers에 authentication으로 토큰 값을 담아 보내기로 했는데, tokens 값은 undefiend 그리고 req 값에는 authentication 자체가 없었다. 알고 보니, 프런트에서 headers에 토큰 값을 담을 때, {authentication : tokenValue}로 보내지 않고, 그냥 tokenValue만 보내고 있었다. (두둥!)토큰 값을 해결하고 다시 포스팅을 확인했지만!! 여전히 내 아이디가 아닌 test1으로 포스팅이 된다!!ㅜㅜ 이상함을 직감한 나(백엔드) 서버에 배포된 파일 중 Posts 라우터를 확인해본다. (잡았다 이놈!) 전 날 완성되지 않은 api를 대체하기 위해 짜둔 mock code가 그대로 붙어있었다!!! (여기에서 userId = 1로 고정되어 있었던 것!!) 교훈: 남 탓하지 말고, 푸쉬한 코드 다시 보자ㅋㅋㅋ
[게시글 수정하기 버튼 활성화 문제]
다른 회원이 작성한 게시글 상세페이지에서, 수정하기 버튼을 눌렀을 때, 게시글 수정 모달이 팝업됨 -> 게시글 상세조회 api를 호출할 때, 로그인한 회원이면 header에 토큰 값을 담아 보내어, 해당 회원의 userId와 게시글을 작성한 회원의 userId를 모두 res하여 프론트에서 버튼 비활성화 기능 추가하기로 함
[aws EC2 서버 컴퓨터에 Docker를 설치하려다가 발생한 문제]
백엔드 서버 EC2에서 docker를 설치하기 위해 yum package manager를 업데이트 하던 와 중에 Segmentation falut error가 나서 EC2 접속을 껐다 다시 켜려고 시도했는데, kex_exchange_identification: Connection closed by remote host 에러가 나면서 접속이 안된다. 앱 서버 자체는 정상적으로 돌아가고, 콘솔에서 인스턴스에 접속만 불가능한 문제였다. 구글링을 통해 여러가지 방법을 시도했지만, 해결되지 않았고, 결국 새 EC2 인스턴스를 파서 백 서버를 다시 띄웠다.
개별 회고
최00
- (좋았던 점) 프로젝트 기획 단계에서 프론트 분들이 개발이 불가능한 부분은 불가능하다고 바로 피드백을 주셨던 점이 성공적인 프로젝트 완성에 가장 주요한 부분이지 않았나 싶다. 기획 단계에서 새로운 기획을 했기 때문에, 개발에 착수해서 시간이 많이 지나고 포기하는 상황을 만들지 않았던 것이 좋았다. 또, 기획 단계에서 프론트와 백이 모두 모여 와이어프레임을 그리고, api를 설계했다. 각자 파트끼리 따로 하는 것이 아니라, 같이 했기때문에, 이후 프로젝트를 진행하며 큰 트러블이 없었다.
- (아쉬운 점) 내가 조금만 더 부지런했더라면, 배포와 관련해서 이런 저런 것들을 더 많이 시도해보고, 배웠을 거라고 생각한다.
- (시간이 더 있었다면...) 시간이 더 있었다면, 코드 리팩토링을 전체적으로 할 수 있었을 것 같고, 도커로 자동배포에 도전했을 것 같다. 또, 애초부터 TDD로 프로젝트를 진행했을 것 같기도 하다.
김00
- (좋았던점) 프로젝트 기획단계에 와이어 프레임 erd설계를 빠르게 정리했고 api 설계를 다같이했었다. 그리고 나의 코드의 부족한점을 하나하나 깃 리뷰를 통해서 코멘트달아주셨던게 너무좋았다
- (아쉬운점) 늦게 합류해서 적은 파트를 받은점 프로젝트에 많이기여못한점.
- (시간이 더 있었다면...) 더 많은 파트 배분이나 게시판 CRUD외에 로그인기능을 도전해봤었으면 좋았을것같다
Ja00
- (Good) pumped to collaborate with FE engineers for this project, and we managed to make the MVP successfully published.
- (Bad) Did not get to work on some extra features such as Docker, OAuth, and so on -- need to manage my time better.
한00
- (좋았던 점) 진.짜 협업을 맛 볼 수 있었던 한 주 였던 것 같습니다. 이슈와 프로젝트 테이블을 사용하여 현황을 함께 보면서 협업 할 수 있었던 점. api 하나하나 작업을 시작하고 끝낼 때 마다 풀, 커밋, 푸쉬 를 해보며 깃을 많이 다뤄 볼 수 있었던 점. pr 후 꼼꼼하고 능력있는 조장님의 댓글들로 지금껏 겨우 기능 동작까지만 확인하고 끝냈던 코드들도 디테일하게 살펴보고 수정,보완 하는 경험들을 많이 해 본 것.
- (아쉬운 점) 개인적으로 3-Layered Architecture 로 코드를 짜는 것이 아직은 요구사항의 작은 변화에도 큰 어려움으로 다가와 시간이 생각 보다 항상 오래 걸렸던 점. 그래서 다른 팀원들에게 조금 더 여유와 안정감을 주지 못했던 점. 아직 기능 구현이 되느냐에만 겨우 초점이 맞춰져 있어서 코드를 꼼꼼하고 좀 더 알맞게? 짜지는 못했던 점. 그래서 그것을 검토하는 과정에서 팀원들의 시간이 많이 소모된 점.
- (시간이 더 있었다면...) 좀 더 실력과 시간이 있었다면 데이터 베이스 구성과 서버 배포 쪽도 해봤으면 좋았을 것 같고, 그 과정에서 필요한 프론트 쪽과의 소통과 협업도 경험해봤으면 좋았을 것 같다.
이성배
- 좋았던 점 협업 재밌었습니다
- 아쉬운 점 이번주까지 배웠던걸 써먹을 수 있어 좋았지만, 챌린지할 시간이 부족했습니다
- 시간이 더 있어따면... 코드가 지저분해서 좀 더 깔끔하게 정리할 수 있었을 것 같습니다.
김00
- (좋았던점) 아직 흐름이 머리로 그려지지 않는데 와이어프레임, api를 모두 공유하며 설계해서 프로젝트를 이해하는데 도움이 되었다. 맡은기능을 구현하는데도 시간이 오래걸리는 편이지만 다른분들께서 맡은 코드도 공유해주시면서 설명 해주시는게 로직을 이해하는데 도움이 되었다. 깃 사용이 어려웠는데 다같이 풀, 푸쉬 과정을 봐주시고 도와주신게 큰 도움이 되었다.
- (아쉬웠던점) 코드를 짜는 속도가 더뎌서 많은 기능을 맡거나 돕지 못한점이 아쉽다 ㅠㅠ
- (시간이 더 있었다면..) 더 많은 기능을 맡아볼 수 있거나 코드를 더 깔끔하게 정리해 볼 수 있었을 것 같다.
'항해99_10기 > 105일의 TIL & WIL' 카테고리의 다른 글
[7주차] [20221226] Notion clone 프로젝트 DB 설계 (1) | 2022.12.27 |
---|---|
[WIL] [6주차] 2022.12.19 ~ 2022.12.25 회고 (feat. 미니프로젝트 완료 후기) (0) | 2022.12.26 |
[6주차] [20221220] (0) | 2022.12.21 |
[6주차] [20221219] Cross Origin Resource Sharing (CORS) (0) | 2022.12.19 |
[WIL] [5주차] 2022.12.12 ~ 2022.12.17 회고 (feat. CORS) (0) | 2022.12.18 |