Pageable에 대한 의존성 문제
- Pageable을 사용하는 것은 도메인, 서비스 등 모두가 Spring Data에 대한 의존성을 갖게 함
- 민재님이 선발대 출발해보고 거기에 따라 구현해보기 ✅
머지한 브랜치 삭제
- 삭제하지 않고 남겨두기로 ✅
application.yml 민감 정보 숨기기
application.yml 민감 정보 숨기기- 민성 제안✅
- 민감 정보를 관리하는 application-secret.yml을 만들다 .
- gitignore에 추가한다.
- 파일은 슬랙이나 게더같은 팀 메신저에서 공유한다.
용어 통합하기
- controller 저장 위치
- /web/api/v0
- /web/api
- /domain/commerce/web/api
- /web/{domain}/api✅
- 응답 객체 네이밍
- 도메인+result
- 도메인+용도 + result ✅
- 복잡한 응답 객체가 불필요한 경우에는 그냥 ResponseEntity<>형태로 작성
이미지 업로드 / 수정 관련 논의사항
- 현 방식
- 업로드 이전: 프론트는 이미지 업로드 전이기에 S3url 위치를 모름
- contents: “글내용 ${image1} 글내용 ${image2}
- 서버에 register 요청 옴: 서버가 S3url을 알게 됨
- 나중에 Get 요청이 올 때 서버에서 처리
${image1}을 → imageData의 url로 대체- 왈라와랄컨텣츠
${image1}컨ㅇㄹㄴㅇㄹ야호!${image2} - [이미지1 메타데이터(s3 url), 이미지2 메타데이터(s3 url)]
- 이미지 수정
- 왈라와랄컨텣츠컨ㅇㄹㄴㅇㄹ야호!
${image2}으악ㅇ장자ㅏㅇ ${image3} - 이미지2는 이미 서버에 저장, 이미지 3은 새로움
- 이미지 1을 지워라 + 이미지3 데이터를 저장하라!
- 싹지우고 다시
Merge 문제
- Github PR의 머지 확인 기능은 겹치는 파일 여부만 체크해줌
- 즉, 컴파일 불가능한 main 브랜치 상황이 생김!
- PR 날리기 전에는 pull + 전체 테스트 실행을 꼭 하자!
로그인 관련 이슈
- 로그인 되어 있는 상태로 간주되게 어떻게 테스트 할 수 있을까?
- MockSecurity 이용하면 될 것 같은데, 아직
In Progress(현정)
- 슈퍼토큰 방식을 사용하면 어떨까? (민성)
이미지 파일 삭제 방식
- 도메인 엔티티
- 이미지 엔티티(ManyToOne 도메인 엔티티)
PreRemove()
S3 관련 테스트
- 파일 리포지터리를 로컬 파일 구현체로 사용