Cookidge 프로젝트를 만들다가 레시피 생성이 안되는 오류를 만나게 되었다. 로컬 환경에서는 잘 동작하지만 배포 환경에서 오류가 발생하는 것이다.
배포 환경에서의 오류라는 점에서, Vercel의 문제인가 확인해 보기 위해 구글링을 해보았다. 그리고 다음과 같은 정보를 얻었다.
Vercel 서버리스는 한 번의 요청 본문 크기에 제한이 있으며, 한 요청 본문 당 4.5MB의 사이즈로 제한한다는 것이다.
Cookidge 레시피 생성 폼을 확인해 보면, 이미지가 들어가는 항목이 많다.
multiple대표 사진- 요리 과정 사진들
정상적인 요리 레시피를 생성한다고 가정했을 때, 한 번의 create요청에 적어도 5개의 이미지가 들어갈 것이다.
해결 방법 후보들
01. 이미지 압축하기 (채택)
폼 onSubmit할 때, 이미지들을 browser-image-compression 라이브러리를 통해 압축하여 제공하는 것이다.
장점
- 서버리스 4.5MB 요청 본문 크기 제한을 해결할 수 있다.
- Cloudinary 저장소 및 Vercel의 무료 한도를 절약할 수 있다.
- 기존의 로직을 유지할 수 있다. 이미지를 압축하는 로직만 추가하면 되기 때문이다.
단점
onSubmit에 압축하는 로직이 포함되어 로딩 시간이 더 오래 걸린다.- 약간의 화질 저하가 생길 수 있다.
02. 이미지 업로드를 따로 따로 요청하기
현재는 한 개의 레시피 폼에서 요리 과정 이미지를 모두 처리하는데, 각각의 요리 과정 저장을 개별 요청으로 하는 것이다. 이렇게 하면 이미지는 4.5MB를 넘을 확률이 줄어든다.
단점
- 요즘 핸드폰은 4000x3000 해상도로 촬영하기에 4.5MB를 넘을 수 있는 경우도 빈번하다.
- 요리 과정은 저렇게 한 번에 보여주는 것이 사용자 경험에 좋다고 판단한다.
- 결국에는 이미지 최적화 기술을 도입해야 한다.
03. 이미지를 서버 거치지 않고, 바로 Cloudinary에 저장하기
장점
-
Cloudinary Api는 리액트에서 바로 저장소에 접근하는 것이 가능하다. 이를 통해 이미지의 URL 또는 Public ID를 요청 본문에 포함 시키면서 4.5MB를 넘기지 않을 수 있다.
-
백엔드의
multer를 사용하지 않아도 된다. 따라서 요리 사진과 요리 과정 사진을 처리하기 위한 복잡한 로직을 제거할 수 있다.
단점
- 일반적인 풀스택 흐름에서 벗어난다. Cloudinary 로직에 너무 종속적으로 된다.
- 이미지 미리보기 기능에서 즉각적인 반응이 안된다. 이미지 미리보기 기능을 위해 각각의 이미지는 Cloudinary 저장소에 업로드하고 다운받는 과정이 생기기 때문이다. (1초 정도 걸림)
결론
해결 방법으로는 1번을 골랐다. 이유는 1번이 장점이 많다기 보다는 2번, 3번의 단점이 크게 작용하기 때문이다. 2번은 딱히 장점이랄 것은 없고, 3번은 이미지 미리보기 로딩이 UX를 크게 저하 시키고, 로직도 꽤나 많이 바꿔야 하기 때문이다.
😑 이번 계기로, Vercel 서버리스의 특징을 새로 알게되고 이에 맞서 싸우는 경험이 생겨 나는 더 강해졌다.
