[Django 웹 프로젝트] 8. 점진적으로 api 로 교체 가능? (2021-11-21)
rest api 로의 전환 필요성
기존 Django 는 rest api 가 아니라, html 까지 렌더링하는 방식이다.
하지만 이 프로젝트는 크게 2가지의 문제상황을 마주하고 있다.
첫째로는 유지보수가 과연 가능할까? 라는 의문이다. 이전의 블로그 포스팅에서 정리되어있다.
[Django 웹 프로젝트] 6. 유지 보수를 위한 새로운 아키텍처 고민 (2021-10-21)
[Django 웹 프로젝트] 7. 유지 보수를 위한 새로운 인가인증 체계 고민 (2021-10-31)
두번째로 어플 제작을 기획 중에 있다는 점이다.
어플을 만들기 위해서는 hybrid app / web app / native 앱을 만들어야한다.
- 네이티브 앱 : SDK기반으로 개발된 애플리케이션. 모바일 플랫폼 API를 이용해 개발한다. 모바일 기기에 직접 다운로드하여 로컬에 저장되는 실행파일로 사용된다.
- 웹 앱 : sdk 가 아닌 브라우저에서 모바일 기기를 인식하여, 해당 화면을 모바일 기기에 맞게 제작하는 것.
- 하이브리드 앱 : 틀은 native 앱이지만, 내용물은 웹앱이다.
하지만 현재 프론트엔드 팀에서 기존 정적파일을 vue.js 전환하고 있고,
프론트 팀의 역량이 충분하지 않다고 판단되어 모바일 어플 팀을 새로 구성, 독립적인 프로젝트를 진행시킬 예정이다.
점진적으로 전환을 할 수 있나?
[(스파게티 코드) + (모바일 어플 제작 필요성) + (프론트엔드의 분리)] 의 상황에서 api 로 새로 제작해야겠다고 다짐했다.
또 현재 db 구조가 확장하기에 매우 불편하고 추가 기능요구사항들을 반영할 수 없다고 판단해서, db 도 조금 손봐야했다.
이런 상황에서도 서비스가 계속 유지되는 것이 제일 중요하니까,
기존의 django 레거시 프로젝트를 줄여나가면서, 점차 api 로 갈아치울 수 있는지를 고민했다.
가장 중요한 것은 로그인 유지에 관한 부분이다.
django 에서는 세션기반이었는데,
rest api 는 보통 토큰 기반의 로그인을 사용한다고 한다.
당시에 정리했던 글에서 발췌하자면(https://github.com/InhaBas/Inhabas.com/discussions/91)
REST api 만들면서 고려해볼점.
스프링을 도입한다면... =>
(세션)
- 사용자가 웹페이지를 탐색하면서 서버 스위칭이 발생 (장고<->스프링)
- 세션을 그대로 사용한다면, 브라우저에 있는 세션 id 를 통해 스프링에서 db에 접근해야함.
=> 스프링을 안해봐서 모르겠다.
(토큰)
- 사용자가 웹페이지를 탐색하면서 서버 스위칭이 발생 (장고<->스프링)
- 브라우저에 있는 토큰의 유효성만 확인하면 됨.
- 기존 장고는 완전히 교체되기 전까지 세션인증 방식과 토큰을 병행. => 기존 권한체계를 고려해야함.
장고를 이어간다면...
(세션)
- DRF 에서 세션을 사용하도록, session id 만 주고 받으면 될 듯.
- 다만 context processor 를 못쓰게 됨. 이게 state를 추적하는데 편리하면서 중요한 역할을 해주고 있다는 생각.
(토큰)
- 최초 소셜로그인 시 토큰 발급 기존 장고는 완전히 교체되기 전까지 세션인증 방식과 토큰을 병행.
=> 기존 권한체계를 고려해야함.
대충 결론 짓자면,
- 두 가지 로그인 방식을 혼합해야하고,
- 기존 권한체계와 더불어 새로운 권한체계가 같이 섞이게 된다.
이런 이유로, 점진적으로 교체하는 건 비효율적이라고 판단했다.
그래서 완전히 새롭게 프로젝트를 파서, 나중에 완성되면 갈아치우는 방식으로 결정했다.