[FEAT/#289] 배너 이미지 pre-sigend url 조회 및 배너 생성 API 구현

[sung-silver]

Related Issue 🚀

• closed [FEAT] 배너 - 생성 #289

Work Description ✏️

• AWS S3 bucket에 이미지 업로드 시 pre signed url을 사용할 수 있도록 했습니다
• 다음과 같이 배너명과 배너를 생성한 일자, 이미지 유형 등이 이름에 포함됩니다

 {
    "success": true,
    "message": "이미지 업로드 pre signed url 조회에 성공했습니다",
    "data": {
        "presigned-url": "https://makers-banner.s3.ap-northeast-2.amazonaws.com/birthday/2024-12-23_happy%28mo%29.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20241222T171034Z&X-Amz-SignedHeaders=host&X-Amz-Expires=1200&X-Amz-Credential=AKIAVQPX6FSLFAUMBS55%2F20241222%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Signature=b27ec52a28f7240a371ab22de0ae5d9a5162013d47d625d2362ebaaff5fd2892",
        "filename": "birthday/2024-12-23_happy(mo).png" // 클라이언트에서 다시 서버로 보내줄 값
    }
}

• pre signed url을 통한 이미지 업로드도 확인 완료했습니다
  

• 배너 생성 API도 확인 완료했습니다
  

• 배너 수정을 위해 S3에서 이미지를 삭제하는 로직을 미리 구현했습니다

동규오빠 작업 머지 이후의 변경사항

1. banner not found 예외 오탈자 수정 (NOT_FOUNT~ -> NOT_FOUND)
2. banner 엔티티에 link 필드 추가(nullable)
3. 캡쳐본에는 반영되지 않았지만, BannerDetail 조회 시에도 link 필드가 같이 내려가도록 했습니다
4. AWS key 관련해서 secret key 부분에 동일하게 access key 환경변수를 적용하고 있던 부분 수정했습니다

PR Point 📸

• 저희 어노테이션에 와일드카드 적용안하는 것 operation에서도 적용일까요? 일부 적용되어있는 클래스가 보여서 없애다가 일단 저도 중간부터는 수정안했습니다!
• S3 퍼블릭 액세스 관련해서 설정이 헷갈려서 시간이 좀 많이 걸렸네요 늦어서 죄송합니다

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[yummygyudon]

작업 고생해셨어요!
제가 미처 구현치 못했던 Exception Handler나 도메인 검증 로직 대신 구현까지 해주셔서 감사드립니다!!

우선 본 프로젝트에서는 와일드 카드에 대해서 지난 기수에는 지양하자고 구두로 합의하긴 했어서
지키면 좋겠지만 강하게 제약하진 않았습니다!!
저는 본 프로젝트에서 작업할 때도 물론 최대한 와일드카드를 지양하려고 노력합니다만 과거 구현체들에서 와일드카드가 적발되는 것도 사실이니
작업하시면서 편하신 방향으로 진행하거나 컨벤션을 이번에 명확하게 정의하는 것도 좋을 것 같아요~~
(의견 궁금합니다!! @sung-silver @hyunw9 )

[yummygyudon]

제가 Enum static 메서드를 무지성 복붙을 한 정황이 포착되었네요 ㅋㅋㅋㅋㅋㅋ 죄송합니다..

---

P3
s3 path가 ContentType이라는 Enum 내부에location이라는 필드로 관리되는 것에 대해서
외부적인 환경 측면의 의미를 값이 포함되어 있어 우려가 되긴합니다!!

[sung-silver]

동규님 리뷰를 받고, contentType에 따라 폴더 경로를 결정할 수 있도록 로직을 분리하다보니 오히려 복잡성이 증가하는 느낌이 들었습니다!

현재 s3Service에서는 호출되는 클래스로부터 버킷이름과 파일 이름을 전달받고 있는데요, 이 과정에서 S3Service 내부에 contentType에 대한 enum을 검사하여 경로를 결정하게 하는 것이 도메인에 대한 의존성이 생긴다고 느껴졌습니다.
(content의 value를 이용하여 경로를 결정 -> 값을 결정하기 위해 물어보는 대상이 어쩌피 ContentType Enum 객체가 됨)

물론 지금 저희 구조에서 의존성을 완벽하게 모두 분리할수는 없겠지만요,, 이대로 가는건 어떨까요?!

[yummygyudon]

좋아요!!
충분히 고민하고 근거를 가지며 결정을 했으니 좋은 것 같습니다!!

[yummygyudon]

• banner not found 예외 오탈자 수정 (NOT_FOUNT~ -> NOT_FOUND)
• banner 엔티티에 link 필드 추가(nullable)
• 캡쳐본에는 반영되지 않았지만, BannerDetail 조회 시에도 link 필드가 같이 내려가도록 했습니다

우하하!! 제가 놓친 부분들인 것 같은데 너무너무 감사합니다!!!!

AWS key 관련해서 secret key 부분에 동일하게 access key 환경변수를 적용하고 있던 부분 수정했습니다

확인 완료...! 근데 이렇게 되어있었으면 기존에도 작동을 안하고 있었던 건가...?

[sung-silver]

• banner not found 예외 오탈자 수정 (NOT_FOUNT~ -> NOT_FOUND)
• banner 엔티티에 link 필드 추가(nullable)
• 캡쳐본에는 반영되지 않았지만, BannerDetail 조회 시에도 link 필드가 같이 내려가도록 했습니다

우하하!! 제가 놓친 부분들인 것 같은데 너무너무 감사합니다!!!!

AWS key 관련해서 secret key 부분에 동일하게 access key 환경변수를 적용하고 있던 부분 수정했습니다

확인 완료...! 근데 이렇게 되어있었으면 기존에도 작동을 안하고 있었던 건가...?

저도.. 그건 모르겠네요 이벤트 브릿지에서도 이 부분을 사용하는 것 같았는데 url 발급이 안되서 에러를 확인하니까 저런 상황이었습니다,,, ㅋㅋㅋㅋㅋㅋ

[sung-silver]

동규님 리뷰를 받고, contentType에 따라 폴더 경로를 결정할 수 있도록 로직을 분리하다보니 오히려 복잡성이 증가하는 느낌이 들었습니다!

현재 s3Service에서는 호출되는 클래스로부터 버킷이름과 파일 이름을 전달받고 있는데요, 이 과정에서 S3Service 내부에 contentType에 대한 enum을 검사하여 경로를 결정하게 하는 것이 도메인에 대한 의존성이 생긴다고 느껴졌습니다.
(content의 value를 이용하여 경로를 결정 -> 값을 결정하기 위해 물어보는 대상이 어쩌피 ContentType Enum 객체가 됨)

물론 지금 저희 구조에서 의존성을 완벽하게 모두 분리할수는 없겠지만요,, 이대로 가는건 어떨까요?!