PWA 구현에서 발생하는 보일러플레이트 문제의 핵심은 오프라인 기능 관련 로직이 애플리케이션의 비즈니스 로직과 독립적으로 유사하게 반복된다는 점입니다. 예를 들어, stale-while-revalidate 캐싱 전략이나 요청 재시도 로직은 어떤 종류의 앱이든 거의 동일하게 적용될 수 있습니다. 이러한 문제를 해결하기 위해 Workbox가 등장했습니다. Workbox는 PWA의 오프라인 기능을 위한 패턴을 추상화하여 제공하는 라이브러리 모음으로, 캐싱, 사전 캐싱, 백그라운드 동기화 등 다양한 기능을 지원합니다. Workbox의 registerRoute 함수와 StaleWhileRevalidate 클래스를 사용하면 기존의 복잡한 서비스 워커 코드를 훨씬 간결하게 작성할 수 있습니다.
Workbox를 Rails 애플리케이션에 통합하는 방법은 크게 두 가지가 있습니다. 첫 번째는 importScripts를 사용하는 클래식 서비스 워커 방식입니다. 이 방식에서는 CDN을 통해 Workbox 라이브러리를 직접 가져오거나, workbox-cli를 사용하여 로컬에 Workbox를 벤더링한 후 서비스 워커 파일에서 임포트할 수 있습니다. 벤더링 시에는 workbox.setConfig({ modulePathPrefix: '/workbox/' })와 같이 모듈 경로를 설정하여 Workbox가 필요한 모듈을 올바르게 찾도록 해야 합니다.
두 번째 방법은 type: 'module' 옵션으로 등록하는 모듈(ESM) 서비스 워커 방식입니다. 이 경우 npm 또는 yarn을 통해 필요한 Workbox 패키지(예: workbox-routing, workbox-strategies)를 설치하고, 서비스 워커 파일에서 ES 모듈 문법을 사용하여 직접 임포트할 수 있습니다. jsDelivr와 같은 CDN에서도 ES 모듈 형태로 직접 임포트하는 것이 가능합니다. 하지만 서비스 워커에서는 Import Maps가 지원되지 않는다는 점을 유의해야 합니다.
또한, Rails의 에셋 파이프라인(Asset Pipeline)이 에셋에 핑거프린팅(Fingerprinting)을 적용하여 파일 이름이 변경되는 문제는 서비스 워커에서 캐싱할 때 복잡성을 야기할 수 있습니다. 이를 해결하는 가장 쉬운 방법은 service-worker.js 파일을 service-worker.js.erb로 변경하고, Rails의 asset_path 헬퍼를 사용하여 핑거프린팅된 정확한 에셋 경로를 동적으로 생성하는 것입니다. 이를 통해 서비스 워커가 항상 올바른 에셋 파일을 참조하도록 할 수 있습니다.