railway api gateway rewrite 설정으로인한 404 error

서버 로컬 환경과 프론트 로컬 환경에서는 말끔히 동작하던것들이 레일웨이로 옮겨서 레일웨이와 통신하면서 잡다한 에러를 마주쳤다.

cors에러부터 시작해서.. 도메인이 달라 쿠키가 브라우저에 전달안되는 현상, 기타 등등..

그중에서 가장 어이없던 에러는 레일웨이 api 게이트웨이 주소 짤림 현상과 rewrite 현상이다.

레일웨이 게이트웨이 주소 짤림 현상

레일웨이 api 게이트를 사용할 때, 레일웨이 컨테이너의 이름이 길면 주소가 짤리는 현상이 발생한다.

예를들면 레일웨이 컨테이너의 이름이 file-service라면 https://file-servce-development.up.railway.ap/** 이런식으로 저장이 되어버린다. (원래 라면 https://file-service-development.up.railway.app/** 이렇게 저장이 되어야함 )

rewrite 현상

레일웨이 게이트웨이 주소 짤림 현상 때문에 file-service를 files로 바꿨던적이 있다. 이렇게했을때 통신할때의 주소는 만약 파일의 업로드를 POST해야한다면, https://railwayURL/files/api/v1/files/upload가 되는데, 어이없게도.. files를 레일웨이가 rewrite해버리면서 중간에 files가 사라져버리는 현상이 있었다.

즉 최종 통신은 https://railwayURL/files/api/v1/upload 가 되어버렸고 404를 띄웠다.

이거를 발견하기까지 수많은 콘솔로그를 찍고 api/v1 이것이 문제인것인가를 찾아봤으며 내가 담당하지않은 file-service였기에 file-service의 코드들을 하나하나 훑어보며 api/v1를 없애는 프리픽스를 했어야했나?? 내가 임의로 수정을 해도되는걸까? 담당하는 사람이 지금 많이 바쁜데 내가 채팅을 걸어도될까?? 를 수없이 고민했다.

지금은 레일웨이 이름을 files->fs로 변경해줬고 정상적으로 동작하는거를 확인했다.

마무리

개발자를 하기를 잘했다고 생각이 드는 순간은 에러를 마주칠때이고, 내가 정말 개발자가 적성이 맞는건가? 의심이 되는 순간 또한 에러를 마주쳤을때이다.

(사실은 사용자의 문제를 해결하는 서비스를 개발했을때가 정말 뿌뜻하고 개발자가 되기를 잘한것같다는 생각을 함미다…)

무튼 오늘 또 하나의 에러를 잡으면서 성장아닌 성장을 한 것 같아.. 다행이다

추가 - api/v1의 이유

라우트에 /api/v1을 붙이는 이유가 뭘까를 찾아봤는데,

API 서버 버전 관리 이 링크에서 알 수 있게 됬다.

한 번 버전이 정해진 이후에는 라우터를 함부로 수정하면 안 되기 때문이다. 왜냐하면 다른 사람이나 서비스가 기존 API를 쓰고 있음을 항상 염두에 두어야 하기 때문이라고한다.