서비스 워커 수명 주기는 예측 가능한 설치 및 업데이트 프로세스를 보장하지만 로컬 개발 주기를 조금 더 미묘하게 만들 수 있습니다.
일반적인 로컬 개발 주기에서 개발자는 파일의 변경사항을 텍스트 편집기에 저장한 다음 브라우저로 전환하여 변경사항을 확인하면 프로세스가 반복됩니다. 서비스 워커가 혼합되어 있는 경우 이 주기는 대체로 동일하지만 개발자가 예상하는 것과 브라우저가 실행하는 것 사이에 차이가 있을 수 있습니다.
로컬 개발 예외
일반적으로 서비스 워커 API는 HTTPS를 통해 제공되는 페이지에서만 사용할 수 있지만 HTTP를 통해 사용할 수 있는 경우에는 이 규칙에 예외가 있습니다.
한 가지 주목할 만한 예외는 localhost를 통해 제공되는 페이지로, 로컬 개발에 적합합니다.
하지만 개발자가 호스트 파일에 localhost 외에 로컬 호스트 이름을 지정하는 것은 드문 일이 아닙니다.
여러 프로젝트에 별도의 호스트 이름이 필요한 로컬 개발 환경에서 필요합니다.
이러한 경우에는 자체 서명 인증서를 프로비저닝하면 됩니다.
보다 편리한 해결 방법은 서비스 워커 테스트에 대해 예외를 생성하도록 브라우저에 지시하는 것입니다.
Chrome의 경우 chrome://flags/#unsafely-treat-insecure-origin-as-secure로 이동하여 안전하지 않은 출처를 지정하여 안전한 출처로 처리합니다.
Firefox는 about:config의 devtools.serviceWorkers.testing.enabled 설정을 통해 안전하지 않은 출처에서 서비스 워커를 테스트하는 방법을 제공합니다.
서비스 워커 개발 보조 도구
서비스 워커를 함께 사용하여 로컬 개발하면 예기치 않은 동작으로 이어질 수 있습니다.
예를 들어 버전이 지정되지 않은 정적 애셋 또는 변경 후 새로고침 시 업데이트될 것으로 예상되는 사전 캐시된 '오프라인 상태' 페이지에 캐시 전용 전략이 있다고 가정해 보겠습니다.
이러한 애셋의 오래된 버전은 항상 Cache 인스턴스에서 제공되므로 업데이트되지 않는 것으로 보입니다.
안타깝게도 서비스 워커는 빌드된 기능만을 수행하지만 테스트를 더 쉽게 할 수 있는 몇 가지 방법이 있습니다.
서비스 워커를 테스트하는 가장 효과적인 방법은 Chrome의 시크릿 창이나 Firefox의 시크릿 브라우징 기능과 같은 시크릿 브라우징 창을 사용하는 것입니다.
시크릿 브라우징 창을 열 때마다 처음부터 다시 시작합니다.
활성 서비스 워커가 없고 열려 있는 Cache 인스턴스가 없습니다. 이러한 종류의 테스트 루틴은 다음과 같습니다.
- 시크릿 브라우징 창을 엽니다.
- 서비스 워커를 등록하는 페이지로 이동합니다.
- 서비스 워커가 예상대로 작동하는지 확인합니다.
- 시크릿 창을 닫습니다.
- 반복
이 프로세스에서는 서비스 워커 수명 주기를 충실하게 모방합니다.
Chrome DevTools Application 패널에서 사용할 수 있는 다른 테스트 도구가 도움이 될 수 있지만 여러 가지 방식으로 서비스 워커 수명 주기를 수정할 수 있습니다.
애플리케이션 패널에는 현재 페이지의 활성 서비스 워커를 보여주는 서비스 워커라는 하위 패널이 있습니다. 각 활성 서비스 워커를 수동으로 업데이트하거나 아예 등록 취소할 수도 있습니다. 또한 상단에는 개발을 돕는 전환 버튼이 3개 있습니다.
- 오프라인은 오프라인 조건을 시뮬레이션합니다. 이는 활성 서비스 워커가 오프라인 콘텐츠를 제공하는지 테스트할 때 유용합니다.
- 새로고침 시 업데이트: 전환하면 페이지가 다시 로드될 때마다 현재 서비스 워커를 다시 가져오고 대체합니다.
- 네트워크 우회: 전환 시 서비스 워커의
fetch이벤트에 있는 코드를 우회하고 항상 네트워크에서 콘텐츠를 가져옵니다.
이는 유용한 전환, 특히 네트워크 우회입니다. 활성 서비스 워커로 프로젝트를 개발하는 경우에 유용하지만 서비스 워커 없이 환경이 예상대로 작동하도록 하려는 경우 유용합니다.
Firefox의 개발자 도구에도 유사한 애플리케이션 패널이 있지만, 이 기능은 설치된 서비스 워커를 표시하는 것 및 현재 페이지의 활성 서비스 워커를 수동으로 등록 취소하는 기능으로 제한됩니다. 이 방법만큼 유용하지만 로컬 개발 주기에 더 많은 수작업이 필요합니다.
Shift 및 새로고침
새로고침 시 업데이트 또는 네트워크 우회에서 제공하는 기능을 사용할 필요 없이 활성 서비스 워커를 사용하여 로컬에서 개발할 때는 Shift 키를 누른 상태에서 새로고침 버튼을 누르는 것이 좋습니다.
이를 강제 새로고침이라고 하며, 네트워크의 HTTP 캐시를 우회합니다. 서비스 워커가 활성화되면 강제 새로고침 역시 서비스 워커를 완전히 우회합니다.
이 기능은 특정 캐싱 전략이 의도한 대로 작동하는지에 대한 불확실성이 있을 때 유용하며, 네트워크에서 모든 것을 가져와서 서비스 워커를 사용한 동작과 사용하지 않은 동작을 비교하는 데 유용합니다. 더 좋은 것은 특정 동작이므로 서비스 워커를 지원하는 모든 브라우저가 이를 관찰할 수 있습니다.
캐시 콘텐츠 검사
캐시를 검사할 수 없다면 캐싱 전략이 의도한 대로 작동하는지 알기 어렵습니다.
물론 캐시는 코드에서 검사할 수 있지만, 이는 시각적 도구가 작업에 더 적합할 때 디버거 또는 console 문이 관련된 프로세스입니다.
Chrome DevTools의 Application 패널에는 Cache 인스턴스의 콘텐츠를 검사하는 하위 패널이 제공됩니다.
이 하위 패널은 다음과 같은 기능을 제공하여 서비스 워커를 더 쉽게 개발할 수 있도록 합니다.
- 인스턴스
Cache개의 이름을 확인합니다. - 캐시된 애셋의 응답 본문과 관련 응답 헤더를 검사할 수 있는 기능
- 캐시에서 항목을 하나 이상 제거하거나 전체
Cache인스턴스를 삭제할 수도 있습니다.
이 그래픽 사용자 인터페이스를 사용하면 서비스 워커 캐시를 검사하여 항목이 서비스 워커 캐시에서 추가, 업데이트 또는 삭제되었는지 쉽게 확인할 수 있습니다. Firefox는 별도의 저장소 패널에 있지만 유사한 기능을 가진 자체 캐시 뷰어를 제공합니다.
스토리지 할당량 시뮬레이션
대용량 정적 애셋 (예: 고해상도 이미지)이 많은 웹사이트에서는 저장용량 한도에 도달할 수 있습니다. 이 경우 브라우저는 오래된 애셋 또는 새 애셋을 위한 공간을 확보하기 위해 희생해야 할 가치가 있다고 생각되는 항목을 캐시에서 제거합니다.
저장용량 할당량 처리는 서비스 워커 개발의 일부여야 하며 Workbox는 이를 직접 관리하는 것보다 더 간단하게 만들어 줍니다. Workbox와 관계없이 맞춤 저장용량 한도를 시뮬레이션하여 캐시 관리 로직을 테스트하는 것이 좋습니다.
Chrome DevTools의 애플리케이션 패널에는 페이지에서 사용 중인 현재 저장용량 할당량에 관한 정보를 제공하는 저장소 하위 패널이 있습니다. 또한 커스텀 할당량을 메가바이트로 지정할 수 있습니다. 적용 시 Chrome은 테스트를 위해 맞춤 저장용량 한도를 적용합니다.
또한 이 하위 패널에는 사이트 데이터 지우기 버튼과 버튼을 클릭할 때 지워야 할 항목에 대한 관련 체크박스 전체가 포함되어 있습니다.
그중에는 열린 Cache 인스턴스와 페이지를 제어하는 활성 서비스 워커의 등록을 취소하는 기능이 포함되어 있습니다.
쉬운 개발, 생산성 향상
개발자가 방해받지 않을 때는 더 자신 있게 작업하고 생산성을 높일 수 있습니다. 서비스 워커를 사용한 로컬 개발은 미묘한 차이가 있을 수 있지만 반드시 어려운 것만은 아닙니다. 이러한 도움말 및 유용한 정보를 활용하면 활성 서비스 워커로 개발하는 것이 훨씬 투명하고 예측 가능해져 개발자 환경이 개선됩니다.