[TIL] 7주차 클론 코딩ㅣAWS EC2 서버 배포

 

클론 코딩 [항해bnb] 진행 상황

 

지난주 금요일의 다짐

바로 오늘! 되든 안되든 배포하기로 한 날이다.
생각보다 기능 구현이 빠르게 되어서
확장 스코프를 제외한 최소한의 스코프는 어느 정도 마무리가 되었다.

 

⭕ 구현 완료된 기능 리스트

1. 회원 

• 로그인
• 회원가입
• 도전! 소셜 로그인

2. 방 CUD

• 방 등록
• 방 수정 (+S3 수정)
• 방 삭제

3. 방 R : 내가 맡은 부분

• 메인 페이지에서 방 전체 조회
• type(호텔, 아파트, 주택) 별 필터링 → 진행 중
• 페이지네이션

4. 다중 이미지 업로드

• S3에 이미지 등록(+방 등록)
• S3에 이미지 삭제(+방 삭제)

5. 좋아요

• 좋아요 추가
• 좋아요 삭제
• 좋아요 여부 반환(true or false)

6. 검색

• 키워드로 검색

 

❓ 구현 예정인 기능 리스트

• 이메일 인증
• 타입별, 가격별 필터링
• swagger 적용

 

클라이언트 쪽에서 빠르게 테스트가 가능하도록
마무리된 기능들 먼저 AWS EC2 서버에 배포하였다.
배포 후 만난 자잘한 에러들은 다음과 같이 해결하였다.

• joinColumn name 변경
  • imageFile Entity의 joinColumn name이 'userid'로 되어있어 'user_id'로 변경해 주었다.
• 전체 조회 시 작성자 이름 출력
  • 전체 조회 시, 해당 글의 작성자가 아닌 현재 로그인된 이름으로 출력되는 에러를 발견하고 RoomService 쪽 로직을 수정하여 작성자가 출력되도록 하였다.
• 카카오톡 닉네임 가져오도록 변경
  • 카카오톡 소셜 로그인 부분에서 해당 유저의 닉네임이 아닌 이메일을 가져오고 있어 닉네임을 가져올 수 있도록 변경하였다.

 

 

 

기술 매니저님의 중간 멘토링 QnA

• 전체 조회에서 비회원 접근을 어떻게 처리하는 게 좋을까요?
  • 로그인 여부에 따라 api를 분리하는 방법
  • 토큰 값 자체를 HttpRequest 사용해서 토큰의 유무 정보 확인하는 방법
  • @AutenticationPrincipal 어노테이션 사용하지 않고, User 객체 자체로 받아서 default value 0으로 설정하는 방법
  • 어떤 방법이 알맞을지 생각해보고 적용하기
• if/else → try/catch 어떤 방식으로 하는 게 알맞을까요?
  • if문 안에 들어오지 않는 모든 경우에 에러로 만들고 싶다? 는 위험함
  • 로직마다 다른 거임! 오히려 else로 throw를 던지는 게 알맞을지도? 상황에 따라!
  • try/catch가 항상 권장은 아니기 때문에 예제를 찾아보는 게 좋음(example로 검색)
  • 그럼 비정상으로 작동했을 때 어떻게 처리할 것인가
  • log를 남겨보는 걸 추천! (logback, 파일로 남길 수도 있음)

 

 

 

오늘의 나는

목표했던 월요일 배포 성공!
오전에 후다닥 배포하고, 에러도 해결하였다.
우리 팀 백엔드 분들이 빠르게 기능 구현을 해주어서 가능했다.

오후에는 팀원분들과 코드리뷰 시간을 가졌다.
소셜 로그인이나 이메일 인증 쪽은 직접 구현한 게 아니다 보니 설명을 들어도 이해가 더뎠다.
아무래도 더 공부를 해봐야 할 것 같다.

백엔드 팀원보다 프론트엔드 팀원이 비교적 적기 때문에 (4:2)
백엔드에서 원하는 기능을 프론트엔드까지 전부 구현할 수는 없을 것 같다는 판단을 했고,
따라서 백엔드의 확장 스코프는 백엔드 쪽만 생각하며 개발하기로 하였다.
프론트엔드 분들의 짐을 조금이라도 덜어드리기 위해서..

아무튼 순조롭게 진행 중!
어떤 결과물이 나올지 벌써 기대된다😚