[임송이] File handling 기능 구현

[Im-amberIm]

구현할 기능

multer와 cloundinary 사용하여 이미지나 문서파일을 cloudinary에 저장후 받은 url을 postgreSQL 데이터베이스에 저장.

세부 작업 목록

• multer config
• cloudinary config
• multer-storage-cloudinary 사용해서 재 구현 할지 고민
• test

참고 사항

[Im-amberIm]

현재 날짜 기준으로 구현한 방식 (Custom CloudinaryService)

현재 방식은 메모리에 파일을 임시 저장한 후 직접 Cloudinary API를 호출하여 업로드하는 방식임.

1. 파일 수신:

• 클라이언트가 파일을 multipart/form-data로 전송
• Multer가 메모리에 파일 임시 저장 (multer.memoryStorage() 사용)
• @uploadedfile() 데코레이터로 컨트롤러에서 파일 객체 수신

2. Cloudinary 업로드:

• 수신한 파일 객체를 CloudinaryService.uploadImage() 메서드에 전달
• 서비스는 Cloudinary SDK를 사용하여 스트림 생성
• 파일 버퍼를 스트림에 파이핑하여 업로드
• Promise를 반환하며 완료 시 URL 반환

3. 데이터베이스 저장:

• 반환된 이미지 URL을 DTO와 결합
• 결합된 데이터를 서비스를 통해 리포지토리에 전달
• 리포지토리가 Prisma를 사용하여 데이터베이스에 저장

특징:

• 업로드 과정을 세밀하게 제어할 수 있음
• 업로드 전/후에 추가 처리 로직 삽입 가능
• NestJS의 의존성 주입 패턴에 잘 맞음
• 스트림 처리와 Promise 관리가 필요함

다른방식 multer-storage-cloudinary 방식

multer-storage-cloudinary는 Multer 스토리지 엔진으로 직접 Cloudinary에 업로드하는 방식

1. 스토리지 설정:

• CloudinaryStorage 인스턴스 생성 및 설정
• 폴더, 형식, 변환 옵션 등 지정
• Multer에 스토리지로 등록

2. 파일 수신 및 업로드:

• 클라이언트가 파일을 multipart/form-data로 전송
• Multer가 파일을 수신하면서 자동으로 Cloudinary에 업로드
• 업로드된 파일의 URL이 file.path에 자동으로 설정됨

3. 데이터베이스 저장:

• file.path에서 URL을 가져와 DTO와 결합
• 결합된 데이터를 서비스를 통해 리포지토리에 전달
• 리포지토리가 Prisma를 사용하여 데이터베이스에 저장

특징:

• 코드가 더 간결해짐
• Cloudinary 업로드 로직을 직접 관리할 필요가 없음
• 이미지 변환 옵션을 스토리지 생성 시점에 지정 가능
• NestJS의 FileInterceptor에서 동적 스토리지 설정이 어려움

이미지 최적화 측면 비교

현재의 수동 업로드 방식:

• 이미지 최적화 옵션을 uploadImage 메서드에 전달해야 함
• 동적으로 옵션을 변경하기 유리함
• 매번 업로드할 때마다 옵션을 지정해야 함
• 코드가 상대적으로 복잡함 (너무 길어...)

multer-storage-cloudinary 방식:

• 이미지 최적화 옵션을 스토리지 설정 시 미리 지정함
• 정해진 용도별로 스토리지를 미리 구성하기 좋음
• 자주 사용하는 옵션 세트를 쉽게 재사용할 수 있음
• 코드가 간결하고 선언적임

로직 차이점 상세 비교

1. 파일 처리 로직:

현재 방식:

• 파일은 메모리에 버퍼로 저장됨
• 서비스 레이어에서 수동으로 cloudinary.uploader.upload_stream 호출
• 스트림에 버퍼 데이터를 파이핑하여 업로드
• Promise를 통해 비동기 처리를 관리하고 URL 반환

multer-storage-cloudinary 방식:

• 파일이 Multer에 의해 수신되는 즉시 Cloudinary로 전송됨
• 업로드 로직이 미들웨어 레벨에서 실행됨
• 컨트롤러 로직이 실행될 때는 이미 업로드가 완료된 상태
• 결과 URL이 file 객체의 path 속성에 자동으로 저장됨

2. 에러 처리:

현재 방식:

• 업로드 과정에서 발생하는 에러를 try/catch 또는 Promise의 reject로 직접 처리 가능
• 세부적인 에러 처리와 로깅이 가능
• 에러 발생 시 사용자 정의 예외를 던질 수 있음

multer-storage-cloudinary 방식:

• 기본 에러 처리는 Multer 미들웨어 내부에서 처리됨
• 업로드 실패 시 HttpException이 자동 발생함
• 세부적인 에러 처리는 더 복잡할 수 있음
• 에러 발생 시 컨트롤러 로직이 실행되지 않음

3. 이미지 최적화 및 변환:

현재 방식:

• 각 업로드마다 다른 변환 옵션을 동적으로 적용 가능
• 요청 내용에 따라 최적화 전략을 변경할 수 있음
• 변환 로직을 서비스 레이어에서 관리해야 함

multer-storage-cloudinary 방식:

• 스토리지 설정 시 미리 변환 옵션 정의
• 자동 포맷 변환(format: 'auto')으로 WebP/AVIF 지원
• 자동 품질 최적화(quality: 'auto')로 용량 절감
• AI 기반 크롭핑(gravity: 'auto')으로 주요 피사체 보존
• 해상도 자동 조정(dpr: 'auto')으로 디바이스 최적화

최종 비교:

현재 방식이 유리한 경우:

• 업로드 과정을 세밀하게 제어해야 하는 경우
• 파일 처리 전/후에 복잡한 로직이 필요한 경우
• 동적으로 다른 업로드 설정이 필요한 경우
• 에러 처리와 로깅을 상세하게 관리해야 하는 경우

multer-storage-cloudinary가 유리한 경우:

• 코드 간소화가 우선순위인 경우
• 이미지 최적화 옵션을 쉽게 활용하고 싶은 경우
• 용도별로 정해진 업로드 구성이 필요한 경우
• 개발 속도를 높이고 보일러플레이트 코드를 줄이고 싶은 경우

결국 이미지 최적화를 중점적으로 활용하려면 multer-storage-cloudinary 방식이 더 간편하게 구현하기 좋은건가?