Service worker 는 웹페이지의 한계를 넘기 위해서 만들어 졌다.
web page 는 다음과 같은 한계가 있었다.
service worker 이를 극복하기 위해서 브라우져 단위에서 지원하는 background service 라 할수 있다. 당연하게도 무엇이든 다할수 있는 것은 아니고 제한사항이 있다.
우선 service worker는 언제 종료 될지 언제 다시 시작 될지 모른다. background service 이지만 언제 종료될지 모르는게 이상하게 느껴지겠지만, 이는 배터리 절약과 같은 이유떄문이다. 만약 안드로이드 앱을 만들어보았다면 activity가 언제 종료 될지 모르는 것과 같다고 생각하면 된다. 즉, service worker는 이벤트가 있어야지만, 비로소 메모리에 로딩되어 실행되며, 동시에 정의된 이벤트를 실행한다. 이벤트가 없으면 바로 메모리에서 내려간다. 체감상 30여초 정도 되는 것 같다. 즉 service worker는 매번 다시 실행 된다고 보는 것이 속편할 정도로 자주 정리된다.
service worker가 반응하는 이벤트는 딱 3가지 이다. sync, push, fetch 가 바로 그것이다. (나머지 이벤트는 자신의 update에 관련된 것이다.)
fetch는 웹페이지의 요청을 모두 가로챈다. 즉 일종의 proxy인것 처럼 동작한다. 네트워크 연결이 끊기기 전에 캐쉬를 받아 두었다가, 매번 요청할때 캐쉬에서 내려줄수 있다. 이로서 네트워크가 끊어져도 동작할수 있는 기반을 제공한다.
push는 web push api를 통해서 활성화 된다. Android의 push 와 같다. 심지어 서버도 같은 서버를 사용한다. 이로써 사용자가 요청하지 않아도 정보를 전송할수 있게 된다.
sync는 조금 특이한데, 네트워크가 끊어져 있다가 다시 붙으면 발생한다. 즉 네트워크 끊어지기 전의 요청을 fetch이벤트에서 받아 두었다가, sync 이벤트에서 전송할수 있다. message 앱에서의 sync 를 연상하면 좀더 이해하기가 쉽다
즉 service worker는 헤비한 background 작업을 하기 위해서 만든것이 아니다. 단지 네트워크가 끊어졌을때의 대비를 위한 background 작업을 하기 위해 만든것에 가깝다. 그래서 여전히 background 작업이 불가능한 문제는 그대로이다. 다만, 그런 헤비한 작업은 보통 server상에서 동작하게 된다. 애시당초 헤비한 작업은 웹페이지 상에서 처리해서는 안된다. 그래서 이 service worker도 그러한 패러다임에 맞춘것이 아닐까 한다.