[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를 추적하는데 편리하면서 중요한 역할을 해주고 있다는 생각.

    (토큰)
        - 최초 소셜로그인 시 토큰 발급 기존 장고는 완전히 교체되기 전까지 세션인증 방식과 토큰을 병행.
            => 기존 권한체계를 고려해야함.

 

대충 결론 짓자면,

1. 두 가지 로그인 방식을 혼합해야하고,
2. 기존 권한체계와 더불어 새로운 권한체계가 같이 섞이게 된다.

이런 이유로, 점진적으로 교체하는 건 비효율적이라고 판단했다.

 

그래서 완전히 새롭게 프로젝트를 파서, 나중에 완성되면 갈아치우는 방식으로 결정했다.