[데브코스] WEEK18🚀

프로그래머스 데브코스 프론트엔드 84일차

2차 스프린트 🥳

2차 스프린트 기능을 산정하고 분배하는 날! 이번에 분배받은 기능은 회원가입, 내 정보 수정 이다. 프론트엔드 팀원들이 거의 매일 같이 새벽을 새면서 기능을 구현하고 있다. 팀장으로 해야할일이 무엇이 있을까라는 고민을 가지고 있다. 아마 이렇게 3차, 4차 스프린트를 거치게 된다면 지쳐버리지 않을까라는 걱정이 생긴다. 이번 스프린트에서도 기능을 최대한 빨리 끝내고 팀원들 일을 줄일 수 있는 것들을 찾아봐야할 것 같다!

프로그래머스 데브코스 프론트엔드 85일차

배포해야겠죠? ☂️

1차 스프린트에서 가장 불편했던 부분은 지라로 이슈관리를 하고 최종 프로젝트에 차곡차곡 쌓아올려도 QA를 할 수 없었다는 점이었다. QA를 하기 위해선 꼭 프론트엔드팀이 백엔드팀과 화면공유로 모든 케이스를 다같이봐야했고 이에대한 리소스 낭비가 크다고 생각했다. 결국, 프론트엔드팀도 배포를 우선적으로 해야겠다!라는 생각을 하게 되었고 배포를 진행했다. 기존 github pages, netlify로 배포를 진행해보았지만 프로젝트 규모가 기존보단 크다고 생각했기 때문에 조금은 걱정되는 마음으로 진행했다. 배포는 무사히 잘 되었지만 SPA인 우리 프로젝트가 netlify상에서 url로 접근 시 404 오류가 나는 문제가 발생했다. 이는 결국 해당 url에 대한 html 파일이 없어 발생하는 문제다. (SPA는 파일이 html이 1개) 이를 해결하기 위해서 url로 접근할 때 마다 index.html로 리다이렉트하게끔 /* /index.html 200 코드를 작성했고, 해결했다!

프로그래머스 데브코스 프론트엔드 85일차

CORS? 드디어 만났군요? 🙈

회원가입 기능을 완성했다. api 연동까지 무리없이 진행되어 내 정보 수정도 무난하게 구현되어가고있던 도중, 문제가 하나 발생했다. 바로 CORS 오류! 웹 개발자라면 한번쯤은 만나야하는 CORS를 두번째 스프린트에서 만나게 되었다. CORS 오류가 발생했던 부분은 내 프로질 이미지와 내 정보를 GET 해온 상황에서 정보를 수정하고, 수정 버튼을 눌렀을 때 발생하는 PATCH에서 발생했다. 우선, 백엔드팀에서 api 수정 부분이 있다는 메세지를 받고 파일을 다루는 FileReader 객체에 대해 공부하기로 결정!

프로그래머스 데브코스 프론트엔드 86일차

해결되지 않는다... 🌪

CORS 이슈가 다른 프론트엔드 팀원 api 호출 시에도 발생하기 시작했다. 이번엔 PUT에서 발생하고 있었고, 마침 프로그래머스 강의장으로 같이 모이는 날이었기 때문에 이를 모여 같이 해결해보기로 했다.
프론트엔드 배포 후 새로운 문제에 봉착했다. 이번엔 크롬에서 발생하는 http 이슈였다. 이는 https에서 배포된 프론트엔드에서 http로 되어있는 백엔드를 호출했기 때문에 보안상 크롬에서 막아서 발생하는 이슈였다. (결국 CORS) 이 두가지 이슈로 인해 프론트엔드, 백엔드 둘다 진도 나가는것을 중단해야했다.

프로그래머스 데브코스 프론트엔드 87일차

휴! 해결!! ☀️

하루종일 CORS 오류로 씨름했다...! 하지만 이를 통해 CORS를 알게 되었으니 충분히 가치있었다고 생각한다. 우선 백엔드팀과 오류에 대해 확인하면서 의문점이 몇가지 있었다.
(1) 왜 PATCH, PUT을 했는데 OPTIONS 메소드가 요청이 오나요?
프론트엔드팀과 백엔드팀 둘다 OPTIONS 메소드에 대해 처음 알게 되었다. http 프로토콜에 요청을 보내는 유형엔 simple request와 multi request가 있다. 이 중 우리가 authorization 라는 이름으로 사용자 토큰을 헤더에 넣어 보내는 것은 multi request다. multi request를 보낼 땐 이 요청을 보내도 되니? 라는 의미로 OPTIONS 요청을 먼저 보내게 된다. 이에 대해서 서버 측에서 적절한 응답을 해주면 PATCH, PUT, POST 뭐 등등의 multi request 요청을 보내게 된다!
(2) 모든 요청에 대해 받을 수 있게끔 설정해두었다! 하지만 오류가 난다!
이 내용은 백엔드팀에서 공유 받았다. 서버는 클라이언트로부터 오는 모든 요청을 받지 않게 설정한다. 하지만 OPTIONS를 위해 재설정을 했지만 같은 오류가 발생하고 있었다. 이는 결국 요청을 받는 보안쪽?에서도 이를 재설정 했어야했지만, 재설정이 되지 않아 발생했던 오류였다. 결국 재설정 후 프로젝트는 무사히 다시 진도를 나가게 되었다.
(3) 그래서 해결법이 뭔데?
우선, 프론트엔드 측에서 할 수 있는 것은 프록시미들웨어를 이용해 안전하게 우회해 요청하는 방법을 찾았다. 하지만 이 방법은 문제에 대한 회피인것 뿐이고 이를 해결하는 근본적인 방법은 CORS 정책에 올바르게 http를 사용하는 것이다. 문제가 해결되고 나중에 알았지만, 이번 CORS 이슈는 PATCH, PUT을 정책에 맞게 사용하지 않아서 발생했다는 점이다. http 프로토콜에 대해 잘 몰랐던 프론트엔드와 백엔드 모두 공부가 필요한 부분이다.