이 페이지는 Cloud Translation API를 통해 번역되었습니다.

다중 출처 사이트의 프로그레시브 웹 앱

다중 출처 사이트에서 프로그레시브 웹 앱을 빌드할 때의 문제와 해결 방법

Demián Renzulli

배경

이전에는 다중 출처 아키텍처를 사용하는 데 몇 가지 이점이 있었지만 프로그레시브 웹 앱의 경우 이 접근 방식에는 많은 문제가 있습니다. 특히 동일 출처 정책은 서비스 워커 및 캐시, 권한과 같은 항목을 공유하고 여러 출처에서 독립형 환경을 실현하기 위한 제한사항을 적용합니다. 이 도움말에서는 여러 출처의 장단점을 설명하고 다중 출처 사이트에서 프로그레시브 웹 앱을 빌드할 때의 문제와 해결 방법을 설명합니다.

여러 출처의 올바른 사용과 잘못된 사용

사이트에서 멀티 오리진 아키텍처를 사용하는 데는 몇 가지 타당한 이유가 있습니다. 대부분 독립적인 웹 애플리케이션 세트를 제공하거나 서로 완전히 격리된 환경을 만드는 것과 관련이 있습니다. 피해야 할 사용도 있습니다.

좋은 예

먼저 유용한 이유를 살펴보겠습니다.

현지화 / 언어: 국가 코드 최상위 도메인을 사용하여 여러 국가에 게재할 사이트를 구분하거나 (예: https://www.google.com.ar) 하위 도메인을 사용하여 여러 위치를 타겟팅하는 사이트를 구분합니다 (예: https://newyork.craigslist.org) 또는 특정 언어로 된 콘텐츠를 제공 (예: https://en.wikipedia.org)할 수 있습니다.
독립 웹앱: 다양한 하위 도메인을 사용하여 기본 출처의 사이트와 목적이 크게 다른 환경을 제공합니다. 예를 들어 뉴스 사이트에서 크로스워드 웹 앱은 의도적으로 https://crosswords.example.com에서 제공되고 기본 웹사이트와 리소스나 기능을 공유하지 않고도 독립형 PWA로 설치되어 사용될 수 있습니다.

나쁜 점

이러한 작업을 하지 않는 경우 프로그레시브 웹 앱을 빌드할 때 멀티 오리진 아키텍처를 사용하면 불리할 수 있습니다.

그럼에도 불구하고 많은 사이트가 특별한 이유 없이 또는 '기존' 이유로 계속해서 이러한 방식으로 구성됩니다. 예를 들어 하위 도메인을 사용하여 통합 환경의 일부가 되어야 하는 사이트의 일부를 임의로 구분하는 경우가 있습니다.

예를 들어 다음 패턴은 사용하지 않는 것이 좋습니다.

사이트 섹션: 하위 도메인에서 사이트의 여러 섹션을 구분합니다. 뉴스 사이트에서 홈페이지가 https://www.example.com에 있고 스포츠 섹션이 https://sports.example.com에, 정치 섹션이 https://politics.example.com에 있는 경우가 많습니다. 전자상거래 사이트의 경우 제품 카테고리에 https://category.example.com, 제품 페이지에 https://product.example.com 등을 사용합니다.
사용자 흐름: 하위 도메인의 로그인 또는 구매 흐름 페이지와 같이 사이트의 여러 작은 부분을 분리하는 것도 권장하지 않습니다. 예를 들어 https://login.example.com 및 https://checkout.example.com을 사용합니다.

단일 출처로 이전할 수 없는 경우 다음은 프로그레시브 웹 앱을 빌드할 때 고려할 수 있는 문제 목록과 해결 방법 (가능한 경우)입니다.

여러 출처의 PWA 관련 문제 및 해결 방법

여러 출처에서 웹사이트를 빌드할 때 통합된 PWA 환경을 제공하는 것은 쉽지 않습니다. 주로 여러 제약 조건을 적용하는 동일 출처 정책 때문입니다. 하나씩 살펴보겠습니다.

서비스 워커

서비스 워커 스크립트 URL의 출처는 register()를 호출하는 페이지의 출처와 동일해야 합니다. 즉, 예를 들어 https://www.example.com의 페이지는 https://section.example.com의 서비스 워커 URL로 register()를 호출할 수 없습니다.

또 다른 고려사항은 서비스 워커는 속한 출처 및 경로 아래에 호스팅된 페이지만 제어할 수 있다는 점입니다. 즉, 서비스 워커가 https://www.example.com에 호스팅된 경우 범위 매개변수에 정의된 경로에 따라 해당 출처의 URL만 제어할 수 있지만 https://section.example.com의 페이지와 같은 다른 하위 도메인의 페이지는 제어하지 않습니다.

이 경우 유일한 해결 방법은 여러 서비스 워커 (출처당 하나)를 사용하는 것입니다.

캐싱

Cache 객체, indexedDB, localStorage도 단일 출처로 제한됩니다. 즉, https://www.section.example.com에서 https://www.example.com에 속한 캐시에 액세스할 수 없습니다.

다음과 같은 시나리오에서 캐시를 적절하게 관리하기 위해 취할 수 있는 몇 가지 조치가 있습니다.

브라우저 캐싱 활용: 기존 브라우저 캐싱 권장사항을 항상 사용하는 것이 좋습니다. 이 기법은 서비스 워커의 캐시로는 할 수 없는 출처 전반에서 캐시된 리소스를 재사용하는 추가 이점을 제공합니다. 서비스 워커에서 HTTP 캐시를 사용하는 방법에 관한 권장사항은 이 게시물을 참고하세요.
서비스 워커 설치를 가볍게 유지: 여러 서비스 워커를 유지 관리하는 경우 사용자가 새 출처로 이동할 때마다 큰 설치 비용을 지불하지 않도록 합니다. 즉, 절대적으로 필요한 리소스만 미리 캐시합니다.

권한

권한은 출처로 범위가 지정됩니다. 즉, 사용자가 출처 https://section.example.com에 특정 권한을 부여한 경우 https://www.example.com와 같은 다른 출처로 이전되지 않습니다.

출처 간에 권한을 공유할 방법이 없으므로 여기서는 특정 기능 (예: 위치)이 필요한 각 하위 도메인에서 권한을 요청하는 것이 유일한 해결 방법입니다. 웹 푸시와 같은 경우 쿠키를 유지하여 사용자가 다른 하위 도메인에서 권한을 수락했는지 추적하여 다시 요청하지 않도록 할 수 있습니다.

설치

PWA를 설치하려면 각 출처에 자체에 상대적인 start_url가 있는 자체 매니페스트가 있어야 합니다. 즉, 특정 출처 (예: https://section.example.com)에서 설치 메시지를 받은 사용자는 다른 출처 (예: https://www.example.com)에서 start_url가 있는 PWA를 설치할 수 없습니다. 다시 말해, 하위 도메인에서 설치 메시지를 받은 사용자는 앱의 기본 URL이 아닌 하위 페이지의 PWA만 설치할 수 있습니다.

또한 각 하위 도메인이 설치 기준을 충족하고 사용자에게 PWA를 설치하라는 메시지를 표시하는 경우 사이트를 탐색할 때 동일한 사용자에게 여러 설치 메시지가 표시될 수 있는 문제도 있습니다.

이 문제를 완화하려면 메시지가 기본 출처에만 표시되도록 할 수 있습니다. 사용자가 설치 기준을 통과하는 하위 도메인을 방문하면 다음과 같은 작업이 실행됩니다.

beforeinstallprompt 이벤트 수신 대기
event.preventDefault()를 호출하여 메시지가 표시되지 않도록 합니다.

이렇게 하면 사이트의 의도하지 않은 부분에 메시지가 표시되지 않도록 하면서 기본 출처 (예: 홈페이지)에는 계속 표시할 수 있습니다.

독립형 모드

독립형 창에서 탐색하는 동안 사용자가 PWA 매니페스트에서 설정한 범위를 벗어나면 브라우저가 다르게 작동합니다. 동작은 각 브라우저 버전 및 공급업체에 따라 다릅니다. 예를 들어 최신 Chrome 버전에서는 사용자가 독립형 모드에서 범위를 벗어나면 Chrome 맞춤 탭을 엽니다.

대부분의 경우 해결 방법이 없지만 하위 도메인에 호스팅되는 환경의 일부 (예: 로그인 워크플로)에는 해결 방법을 적용할 수 있습니다.

새 URL(https://login.example.com)이 전체 화면 iframe 내에서 열릴 수 있습니다.
iframe 내에서 작업이 완료되면 (예: 로그인 프로세스) postMessage()를 사용하여 iframe에서 얻은 결과 정보를 상위 페이지로 다시 전달할 수 있습니다.
마지막 단계로, 메시지가 기본 페이지에서 수신되면 리스너를 등록 취소하고 iframe을 DOM에서 삭제할 수 있습니다.

결론

동일 출처 정책은 일관된 PWA 환경을 제공하기 위해 여러 출처 위에 빌드된 사이트에 많은 제한사항을 적용합니다. 따라서 사용자에게 최적의 환경을 제공하려면 사이트를 여러 출처로 나누지 않는 것이 좋습니다.

이미 이러한 방식으로 빌드된 기존 사이트의 경우 다중 출처 PWA가 올바르게 작동하도록 하기가 어려울 수 있지만 몇 가지 해결 방법을 모색했습니다. 각 방법에는 장단점이 있으므로 웹사이트에 적용할 접근 방식을 결정할 때는 신중하게 판단하세요.

장기 전략 또는 사이트 디자인 변경을 평가할 때는 멀티 오리진 아키텍처를 유지해야 할 중요한 이유가 없다면 단일 출처로 이전하는 것이 좋습니다.

기술 검토 및 제안을 제공해 주신 다음 분들께 감사드립니다.페니 맥라클랜, 폴 코벨, 도미니크 응, 알베르토 메디나, 피트 르페이지, 조 메들리, 체니 차이, 마틴 슈어러, 안드레 반다라