Facts
- 지하철 노선도 미션 1단계 피드백을 모두 반영했다.
- 2단계의 역 생성을 구현했다.
- try...catch에 대해 조금 더 잘 알게 되었다.
Feelings & Findings
지하철 노선도 미션 1단계 피드백을 모두 반영했다.
실시간으로 회원가입을 할 때, input의 validation을 체크해주는 것을 어제 구현했다. 오늘은 이어서 로그인을 구현했고, 이 부분에 대해 크루들과 예상치 못한 의견 대립이 생겼다.
로그인을 할 땐 이메일 형식이 아니라는 메시지를 띄워주는 서비스가 없고, 그렇기 때문에 잘못됐다는 의견이 있었다. 하지만 내가 생각할 땐 그런 서비스가 없을 뿐이지 잘못된 것은 아니라고 생각해서 기능을 빼지 않았다.
이유는 간단하게 UX적으로 괜찮다고 생각한다. 아무리 생각해봐도 있어서 나쁠 것이 없는 것 같다.
사실 이미 input을 실시간으로 검사하는 함수를 추상화했기 때문에 로그인을 구현하는 것은 어렵지 않았고, 시간도 오래 걸리지 않았다.
시간이 오래 걸렸던 부분은 로그인 토큰 저장 공간이었다. 세션 스토리지와 로컬 스토리지, 쿠키에 대해 크루들과 모여서 이야기를 나눴다.
각각의 장단점이 존재했다.
- 로컬스토리지 => 인터넷을 종료해도 로그인 유지 가능
- 세션스토리지 => 인터넷을 종료하면 로그인 풀림 - 로그인을 유지시킬 이유가 없다는 주장
- 쿠키 => expire time이 존재해서 서버와 동일한 유지 시간인 1시간으로 유지시키면 굳이 로그인 정보 조회 api를 보내지 않아도 된다는 생각, HttpOnly를 사용하면 xss, csrf 공격에도 안전
모두의 단점 => xss, csrf 공격에 취약(HttpOnly 쿠키 제외)
이렇게 요약되었다. 난 굳이 로그인 정보 조회 api를 보낼 필요 없이 쿠키로 체크를 하면 된다고 생각했고, 만약에 로그인이 풀려있는데 클라이언트단에서 로그인을 유지시켰다고 해도 노선 조회와 같은 api 요청을 보냈을 때, 에러가 발생할 것이기 때문에 그때 로그인 페이지로 돌려보내면 된다고 생각했다.
HttpOnly를 사용해보고 싶었지만 아무리 해봐도 서버에서 어떤 조치를 취해야 하는 것 같다. 서버에서 httpOnly : true를 사용하면 되는 것 같기도 한데 정확하지 않다.
어쨋든 쿠키를 사용하기로 했고, 구현을 마친 상태이다.
2단계의 역 생성을 구현했다.
이미 request와 관련된 함수 추상화를 잘 했기 때문에 역 생성 자체는 어렵지 않았다. 30분도 안걸린 것 같다. 하지만 10시가 되어서 더이상 하지 못했고, 내일 2단계 미션을 최대한 많이 해보려고 한다.
try...catch에 대해 조금 더 잘 알게 되었다.
로그인과 회원가입을 할 때 콘솔창에 계속 에러가 찍히는 것을 확인할 수 있었다. 이것은 catch에서 throw new Error을 했기 때문인데, catch가 마지막으로 실행되고 그 다음 코드에 catch가 없기 때문에 콘솔에 에러가 찍히는 것이었다.
처음에는 어쩌피 사용자는 콘솔창을 보지 않을 것이고, 큰 오류는 아니라고 생각했기 때문에 그냥 넘어갔다. 하지만 생각해보니 이런 서비스는 본 적도 없고, 에러가 나는 것이 좋은 상황은 아니라고 생각했다. 그런데 어떻게 고쳐야 할지 감이 잡히질 않았다.
그러던 와중에 한 크루가 이 코드를 사용하는 쪽에서 try..catch를 사용하고, catch에서 아무 것도 하지 않으면 될 것 같다는 의견을 냈고, 성공적이었다.
하지만 try만 하고 catch{}로 끝나기 때문에 뭔가 이상하다. 이렇게 사용하면 안될 것 같지만 catch에서 할 일이 없다. 구글링을 해보니까 finally도 사용하기는 하는 것 같은데 역시나 할 일이 없다. 그래서 일단은 리뷰를 받아볼 생각이다.
Plans
- 지하철 노선도 2단계 미션 최소한 역 관리는 마무리하기
- 이벤트에 대해 공부하기 (스터디 대비)
