Intro
CSR(Client Side Rendering)기반의 웹 애플리케이션은 html을 초기에 한번만 로드하고 이후에 모든 동작은 js에 의해 이루어지기 때문에 앱을 수정한 뒤 빌드하여 다시 배포하더라도 유저가 브라우저를 새로고침 하거나 새로 유입되지 않는 이상 배포했던 내용이 유저의 화면에 반영되지 않는다. 간단한 내용이 수정되었다면 크게 상관 없겠지만 중요한 기능이 수정되었다거나 크리티컬한 버그가 픽스되었다면 유저가 계속해서 이전 버전을 이용하는 것은 문제를 야기시킬 가능성이 높다. 이러한 경우를 해결했던 경험을 기록하려고 한다.
현재 사용중인 앱이 최신인지 알기위한 방법
1. 앱 버전
최신인지 알려면 비교가 필요하고 비교를 하려면 비교할 대상이 필요하다. 가장 먼저 떠오르는 것은 앱의 버전이다. 앱의 버저닝을 충실히 하고 있다면 package.json에 앱의 버전이 기재되어 있다. 이 버전 정보와 최신 앱의 버전과 비교를 하면 현재 앱이 최신인지 알 수 있다. 하지만 최신 앱의 버전은 어떻게 알 수 있을까?
앱을 배포할 때 디비에 버전을 기록하고 비교해야할 시점에 api를 통해서 가져오면 된다. 하지만 이 방법의 경우 앱을 배포할 때 마다 디비의 앱 버전을 수정해 줘야 하기 때문에 번거롭기도 하고(배포 스크립트나 hook으로 자동화는 가능할 것 같다) 별도 api를 만들기도 해야 한다.
2. 최근 수정 시간
프로젝트의 배포환경은 AWS의 S3와 Cloud Front를 사용하고 있다. Cloud Front는 응답 헤더에 last-modified를 보내준다. 이를 local-storage에 저장해 두고 비교 시점에 HEAD Method로 index.html을 요청한 뒤 비교를 하게 되면 현재 앱이 최신인지 알 수 있다. 이 방법의 경우에는 Cloud Front를 사용하지 않을 경우 불가능 하지만 추가 개발이나 버전 관리가 필요 없어 간편하게 구현할 수 있다.
비교 시점
앱을 사용하는 도중에 갑자기 새로고침되거나 새로고침을 유도하는 팝업이 뜬다면 유저의 경험을 해칠 수 있기 때문에 라우터 이동 시점을 비교하는 시점으로 결정 되었다.
비교 후 처리
라우터 이동 시점일지라도 강제 새로고침은 유저에게 혼란을 줄 가능성이 높다고 생각했다. 유저가 여러 스탭의 폼을 작성하고 있을 가능성도 있고 SPA에서 앱에 의해서 강제 새로고침은 매우 어색한 동작이기 때문이다. 따라서 새로고침을 유도하는 문구와 함께 팝업을 띄우는 것으로 결정 되었다.
