서비스 워커 수명 주기는 예측 가능한 설치 및 업데이트 프로세스를 보장하지만 지역 개발 주기를 조금 더 세밀하게 만들 수 있습니다.
일반적인 로컬 개발 주기에서 개발자는 파일 변경사항을 텍스트 편집기에 저장합니다. 브라우저로 전환하여 변경사항을 확인하면 프로세스가 반복됩니다. 서비스 워커가 혼합되어 있는 경우, 이 주기는 대체로 동일합니다. 하지만 개발자가 기대하는 것과 브라우저가 수행하는 작업 간에 차이가 있을 수 있습니다.
로컬 개발 예외
일반적으로 서비스 워커 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가 있거나 없는 경우 커스텀 스토리지 할당량을 시뮬레이션하여 캐시 관리 로직을 테스트하는 것이 좋습니다.
<ph type="x-smartling-placeholder">
Chrome DevTools의 Application 패널에는 페이지에서 현재 사용 중인 저장용량에 대한 정보를 제공하는 저장소 하위 패널이 있습니다. 또한 커스텀 할당량을 메가바이트 단위로 지정할 수도 있습니다. 이 변경사항이 적용되면 Chrome에서 테스트할 수 있도록 맞춤 저장용량 한도를 적용합니다.
또한 이 하위 패널에는 사이트 데이터 지우기 버튼과 버튼을 클릭할 때 삭제해야 하는 항목에 대한 일련의 관련 체크박스도 포함되어 있습니다.
이러한 항목에는 열려 있는 Cache 인스턴스와 페이지를 제어하는 활성 서비스 워커의 등록을 취소하는 기능이 있습니다.
손쉬운 개발, 생산성 향상
개발자는 방해 요소가 없을 때 더 자신 있게 작업하고 생산성을 높일 수 있습니다. 서비스 워커를 사용한 로컬 개발은 미묘한 차이를 반영할 수 있지만, 문제 없이 진행할 수 있습니다. 이러한 요령과 요령을 활용하면 활발한 서비스 워커로 개발하는 것이 훨씬 더 투명하고 예측 가능해야 합니다. 개발자 환경을 개선할 수 있습니다.