- nextJS
- tailwindCSS
- typescript
- jwt
- 반응형으로 구현
- parallel routes & intercepting route를 사용한 모달 구현
- 회원 가입 페이지
- 아이디 & 이메일의 중복 불가
- 로그인 페이지
- 로그인 성공 시, BE로부터 jwt 반환 & 추후 로그인 사용자 요청은 jwt를 매번 전송(쿠키 같은 방식 이용)
- 로그아웃 기능
- 투표 페이지
- 파트장 투표 : 본인 파트의 파트장만 투표 가능
- 공통
- 로그인 한 사용자만 투표 가능 / 로그인 안한 사용자도 조회 가능 but 투표는 불가능
- 본인 혹은 본인이 속한 팀에 투표 불가
- 투표는 한 번만 가능
- 투표 결과 페이지
- 로그인 안한 사용자도 조회 가능
- 투표 수 동일 시 공동순위
로그인 기능이 필요한 웹 페이지에는 인증을 어떻게 할 것인가?의 논쟁이 있다고 생각합니다. 제가 생각하는 인증의 구현 방식은 크게 2가지입니다
- 세션 기반의 인증 방식 : 백엔드 서버는 로그인 정보를 기반으로 세션을 생성하고, 이를 브라우저에게 반환합니다. 백엔드 서버는 이를 데이터베이스에 넣어두거나, 자체 메모리에 올려두는 방식으로 추후 사용자의 인증 요청을 진행합니다. 이는 상태성을 지니는 것이므로, 무상태성을 지녀야 수평 확장을 할 수 있는 백엔드 시스템을 구축하기에 불리한 측면이 있습니다.
- jwt 토큰 기반의 인증 방식 : 서버는 비밀키만을 보유하고, 프론트엔드(브라우저)에서 jwt를 보관하고 있다가 전송하면 이를 해석하여 인증을 시도합니다. 이는 백엔드 시스템을 stateless 하게 설계할 수 있다는 장점이 있습니다.
CORS 정책은 브라우저 자체 단에서 출처(프로토콜 + 도메인 주소 + 포트번호)가 다를 경우 요청을 차단하는 개념입니다.
- preflight 요청 : option 메서드로 전송되며, 백엔드 서버에서
Access-Control-Allow-Origin헤더에 프론트엔드의 주소가 포함되어 있어야 합니다. - jwt와 같은 토큰 정보를 헤더에 싣어보낼 때,
Access-Control-Expose-Headers헤더에 해당 정보를 보내는 헤더명을 명시해주면 프론트엔드에서 Javascript로 접근할 수 있습니다.
nextJS는 서버 사이드 렌더링을 지원하는 reactJS 기반의 프레임워크입니다. 기존의 styled-components 같은 라이브러리를 이용하여 스타일링을 진행하면, 내부적으로 reactJS의 상태 개념을 이용하여 만들어낸 hash 값을 클래스명으로 이용하기 때문에 로직이 클라이언트 단에서 이루어집니다. 만약 Javascript 실행 속도가 느린 환경이라면 사용자에게는 스타일링이 적용되지 않은, 단순 html 즉 layout만 보이는 순간이 존재할 수도 있습니다. 따라서 전처리기, 후처리기의 원리를 차용한 tailwindCSS를 이용하면 좀 더 편하지 않을까 싶습니다.
-
은수 그동안 백엔드 없이 구현했기 때문에 겪을 수 없던 CORS, 토큰관련 문제들을 경험해볼 수 있어서 좋았습니다. 모달을 만들 때 리액트에서 처럼 createPortal이 아닌 parallel & intercepting routes를 사용해 만들어 모달이 라우팅되는 것처럼 구현했는데 익숙치 않아서 그런지 더 번거로운 느낌이 들어 빨리 익숙해지고 싶다는 생각이 들었습니다. 쿠키를 사용하는 것, 중복된 코드들에 대한 리팩토링을 하지 못한 아쉬움이 남습니다. 본격적으로 프로젝트를 시작하게 되면 처음부터 재사용성을 고려한 코드를 작성해야겠다는 다짐을 했습니다.
-
승완 지난 과제를 진행할 때에는 어떤 컴포넌트는 서버 컴포넌트로 만들 것인지를 많이 고민하면서 했는데, 이번에는 백엔드와의 cors 이슈를 해결하느라 이에 대해 다소 소홀했던 것 같습니다. 또한 사실 jwt를 쿠키에 저장해두고, 매번 자동으로 브라우저의 동작 원리에 따라 jwt를 쿠키에 담아 백엔드 단으로 전송하는 로직이 좀 더 바람직한데, 이를 하지 못한 것 같아 다소 아쉽습니다. accessToken과 refreshToken을 각각 클라이언트에서 어떻게 저장할지 고려해보면 더 좋을 것 같습니다.