배경
현재 플랩풋볼은 모놀리식 Django 프로젝트로 구성되어 있습니다. django template 코드와 cdn으로 사용하는 프론트엔드 프레임워크, 그리고 서버에서 context로 보내는 정보를 받아서 사용하는 오래된 코드 베이스가 있습니다. 이러한 구조는 긴 배포 시간과 프론트엔드 프레임워크를 제대로 사용할 수 없어 개발자의 자유도를 떨어뜨리고 생산성을 저해하고 있었습니다. 플랩풋볼 개발팀은 오래된 코드 베이스를 최소한으로 수정하면서 효율적인 프론트엔드를 구축할 수 있는 방법을 고민했습니다.
장기적으로는 프론트엔드 서버와 백엔드 서버의 분리를 고려하고 있습니다.
plabfootball-servernew-backend-server계획이 변경됐습니다. 프론트엔드에서 모놀리식 아키텍처를 유지하고 번들 js파일 로드, 라우팅 개선을 결정하면서 당장 프론트엔드와 백엔드 서버를 분리할 이유가 없어졌습니다. 즉, API를 이전할 필요가 없습니다. 기존 서버 세션 방식의 인증 방식을 토큰 인증 방식으로 변경하는 작업과 새로운 백엔드 서버에서 기존 백엔드 서버로 호출할때의 인증을 변경하는 작업을 합니다.
굳이 할 필요가 없다고 생각할 수도 있습니다. 지금 운영중인
new-backend-server 에서 매니저 앱과 일부 매니저 API를 JWT(Json Web Token) 방식으로 사용하고 있어, 두 서버의 인증 방식이 다르다는 점은 추후 보안적으로 이슈가 생길 여지가 있다는 점을 이유로 plabfootball-server도 JWT 방식으로 변경하여 같은 방식으로 관리하는 것이 나은 방식이라고 판단했습니다.
JWT 인증 방식으로 변경
플로우 차트로 필수 기능을 살펴보고 자세한 구현까지 확인해보자.
로그인(토큰 생성)
리소스 접근(토큰 검증)
재발급
로그아웃(블랙리스트 추가)
협업하는 방법
2명의 개발자가 협업하는 방법을 설명한다.
JWT가 도입됐다
기존의 서버 세션 방식의 인증이 토큰 방식의 JWT로 변경됐다. 그래서 뭐가 달라졌을까? 서버 세션의 단점과 토큰 방식의 장점은 너무나 당연하다.
이전에는 DB에 매번 세션 정보를 업데이트 하고 있었다. 이미 20만 레코드를 훌쩍 넘게 쌓인 테이블을 더 이상 사용하지 않게 됨으로써 I/O 의 관점으로 많은 리소스를 줄였다.
JWT로 전환하면서 토큰에 이미 인증 관련 정보를 내장하고 있어 서버 사이에서 정보를 공유할 필요가 없이 토큰만으로 인증을 처리하게 된다는 이점이 있다.
댓글