에러
배포된 서버 에러 로그
난 역시 아직 애송이인가?
로컬에서 작업하다가 나는 에러는 IDE 터미널로 확인 가능했는데, 배포 주소에서 에러가 날 땐 500 Internal server error만 달랑 던져줘서 답답해 미칠뻔했다.
근데? 친절히 배포해주는 vercel이 친절히 log도 관리해주더라고요?
Log 탭 보자마자 친절히 에러 다 설명해주고 있었다
이래서 사람은 아는 만큼 보인다고...
vercel 에러 로그를 애용해야지!
Sentry라는 새로운 것도 알게 되었다
free plan 있으니까 이것도 붙여봐야지~
http status
status에 따라서 에러를 핸들링하는 습관을 들여야한다.
status에 따라 함수마다 정의해야할까..?란 의문은 역시 초보 개발자의 생각이였던 것.
middleWare를 통해서 status에 따른 에러들을 던져줄 수 있음!
(개인적으로 react에서 HOC 같은게 middleWare다~라고 이해함!)
이미지 업로드 기능
테이블에 쑤셔 넣기
사실 storage를 S3만 생각해서 돈 안들고 이미지 업로드 기능 사용하기를 목적으로 테이블에 억지로 쑤셔 넣기 구현을 했다.
1. base64 형태 그대로 넣기
base64 형태로 넣는건 간단해서 제일 처음 시도했다.
역시 base64는 용량이 너무너무 커서 읽어 오는 시간이 너무 길어져버렸다.
테이블에서 확인하는 것 역시 버벅이기 시작했다.
2. 로컬에 이미지 저장하고 해당 path로 읽어들이기
파일서버를 활용해서 public 폴더에 해당 이미지를 저장하고 해당 이미지 경로를 db에 넣는 방식을 시도했다.
내 마음대로 되질 않아서 정말 한참을 낑낑거린 끝에 성공!
...하자마자 문제를 발견^-^
로컬에서는 post,get이 다 문제 없었는데 배포주소에서 업로드하기만 하면 에러가 났다.
생각해보니 build 되면 로컬 파일 구조처럼 그대로 안올라가...
path를 갖고 있어도 그 path가 있을리 없지..
3. vercel storage
이제 내가 시도해 볼 방법이다.
vercel storage에 업로드 하고 url을 db에 저장!
vercel에 배포하고 db도 갖고 있으니 vercel storage를 활용하면 더 간편하지 않을까...?
제발...
Typescript
급한 마음에 타입 없애겠다고 as를 막 붙여놨었다
바로 들켜버렸지 뭐야
as랑 any 쓰지 말자!!!
넌 사람이라 프로그램에서 뱉어내는 타입이 뭔지 몰라.
함수 만들기
함수는 만들 때마다 어디부터 어디까지 분리해야 할지가 너무 어렵다.
- input, output -> 근본적인 것 부터 생각해보기
- 함수 전체가 if문에 포함되는 내용이라면 반대로 early return 사용하기
역시나 근본적인 것부터 생각해야 하는데 '근본적인 것'을 생각하는거 자체가 너무 어렵다.
이미지 업로드에 너무 많은 시간을 쏟아서 목표였던 jest test는 하지도 못했다.
다음주까지 꼭 test 작성해서 이야기해보기!!!
