사용자가 동일한 조직 또는 서비스에 속해 있음을 알 수 있도록 동일한 도메인 이름을 활용하여 여러 PWA를 빌드하는 방법
다중 출처 사이트의 프로그레시브 웹 앱 블로그 게시물에서 데미안은 여러 출처를 포함하는 단일 프로그레시브 웹 앱을 빌드하려고 할 때 여러 출처를 기반으로 구축된 사이트가 직면하게 되는 문제를 설명했습니다.
이러한 유형의 사이트 아키텍처의 예로는 전자상거래 사이트가 있습니다.
- 홈페이지는
https://www.example.com에 있습니다. - 카테고리 페이지는
https://category.example.com에서 호스팅됩니다. https://product.example.com의 제품 세부정보 페이지
이 문서에서 설명한 것처럼 동일 출처 정책은 여러 출처를 적용하여 서비스 워커, 캐시, 권한을 출처 간에 공유하는 것을 방지합니다. 따라서 이러한 유형의 구성을 피하고, 이미 이러한 방식으로 사이트가 빌드되어 있는 경우 가능한 경우 단일 출처 사이트 아키텍처로 이전하는 것이 좋습니다.
이 게시물에서는 반대의 경우를 살펴보겠습니다. 여러 출처의 단일 PWA 대신 동일한 도메인 이름을 활용하여 여러 PWA를 제공하려는 회사의 사례를 분석한 후 이러한 PWA가 동일한 조직 또는 서비스에 속한다는 사실을 사용자에게 알립니다.
이미 눈치채신 분도 계시겠지만, 여기서는 서로 다르지만 상호 연결된 용어(예: 도메인, 출처)를 사용합니다. 계속 진행하기 전에 이러한 개념을 살펴보겠습니다.
기술 용어
- 도메인: DNS (도메인 이름 시스템)에 정의된 일련의 라벨입니다.
예를 들어
com와example.com은 도메인입니다. - 호스트 이름: 하나 이상의 IP 주소로 확인되는 DNS 항목입니다. 예를 들어
www.example.com은 호스트 이름이고,example.com은 IP 주소가 있으면 호스트 이름이 될 수 있으며,com는 IP 주소로 확인되지 않으므로 호스트 이름이 될 수 없습니다. - 출처: 스키마, 호스트 이름, 포트 (선택사항)의 조합입니다. 예를 들어
https://www.example.com:443는 출처입니다.
이름에서 알 수 있듯이 동일 출처 정책은 출처에 제한을 적용하므로 이 문서 전체에서 주로 이 용어를 언급합니다. 하지만 다른 '출처'를 만들기 위해 때때로 '도메인' 또는 '하위 도메인'을 사용하여 사용되는 기술을 설명합니다.
관련된 여러 PWA의 경우
때에 따라 독립적인 앱을 빌드하되 동일한 조직 또는 '브랜드'에 속한 것으로 식별해야 할 수 있습니다. 동일한 도메인 이름을 재사용하는 것이 이 관계를 설정하는 좋은 방법입니다. 예를 들면 다음과 같습니다.
- 전자상거래 사이트에서 판매자가 인벤토리를 관리할 수 있는 독립형 환경을 만들면서도 사용자가 제품을 구매하는 기본 웹사이트에 속하는지 여부를 확인하려고 합니다.
- 한 스포츠 뉴스 사이트에서 사용자가 알림을 통해 좋아하는 경기에 관한 통계를 받아 프로그레시브 웹 앱으로 설치하면서 이 앱을 뉴스 회사에서 만든 앱으로 인식하도록 하는 주요 스포츠 이벤트에 관한 특정 앱을 빌드하려고 합니다.
- 회사에서 채팅, 메일, 캘린더 앱을 별도로 빌드하여 회사 이름에 연결된 개별 앱으로 작동하게 하려고 합니다.
별도의 출처 사용
이와 같은 경우에 권장되는 방법은 개념적으로 고유한 앱마다 자체 출처에 상주하는 것입니다.
모든 도메인 내에서 동일한 도메인 이름을 사용하려면 하위 도메인을 사용하면 됩니다. 예를 들어 여러 인터넷 앱 또는 서비스를 제공하는 회사는 https://www.example.com에서 비즈니스의 기본 서비스를 제공하면서 https://mail.example.com에서 메일 앱을 호스팅하고 https://calendar.example.com에서 캘린더 앱을 호스팅할 수 있습니다. 또 다른 예로는 사용자가 https://www.example.com에서 호스팅되는 주요 스포츠 사이트와 별개로 설치하여 사용할 수 있는 https://footballcup.example.com의 축구 챔피언십과 같이 중요한 스포츠 이벤트 전용으로 독립적인 앱을 만들려는 스포츠 사이트가 있습니다. 이 접근 방식은 고객이 회사 브랜드로 자체 앱을 만들 수 있는 플랫폼에도 유용할 수 있습니다.
판매자가 https://merchant1.example.com, https://merchant2.example.com 등에서 자체 PWA를 만들 수 있는 앱을 예로 들 수 있습니다.
서로 다른 출처를 사용하면 앱 간 격리가 보장됩니다. 즉, 각 앱이 다음과 같은 다양한 브라우저 기능을 독립적으로 관리할 수 있습니다.
- 설치 가능성: 각 앱에는 자체 매니페스트가 있으며 설치 가능한 자체 환경을 제공합니다.
- 저장소: 각 앱에는 자체 캐시, 로컬 저장소, 기본적으로 모든 형태의 기기 로컬 저장소가 있으며 앱을 다른 앱과 공유하지 않습니다.
- 서비스 워커: 각 앱에는 등록된 범위를 위한 자체 서비스 워커가 있습니다.
- 권한: 권한도 출처로 범위가 지정됩니다. 이를 통해 사용자는 자신이 어떤 서비스에 권한을 부여하는지 정확하게 알 수 있으며 알림 등의 기능은 각 앱에 올바르게 표시됩니다.
독립적인 여러 PWA의 사용 사례에서는 이렇게 어느 정도의 격리를 만드는 것이 가장 바람직하므로 이 방법을 적극 권장합니다.
하위 도메인의 앱이 서로 로컬 데이터를 공유하려는 경우 쿠키를 통해 계속 공유할 수 있습니다. 또는 고급 시나리오에서는 서버를 통해 스토리지를 동기화하는 것이 좋습니다.
동일한 출처 사용
두 번째 접근 방식은 동일한 출처에 여러 PWA를 빌드하는 것입니다. 여기에는 다음과 같은 시나리오가 포함됩니다.
겹치지 않는 경로
동일한 출처에서 호스팅되고 경로가 겹치지 않는 여러 PWA 또는 개념적 '웹 앱' 예를 들면 다음과 같습니다.
https://example.com/app1/https://example.com/app2/
경로 중복/중첩
동일한 출처에 있는 여러 PWA(하나의 범위가 다른 PWA 내부에 중첩되어 있음)
https://example.com/('외부 앱')https://example.com/app/('내부 앱')
서비스 워커 API와 매니페스트 형식을 사용하면 경로 수준 범위 지정을 사용하여 위 작업 중 하나를 수행할 수 있습니다. 그러나 두 경우 모두 동일한 출처를 사용하면 많은 문제와 제한사항이 있습니다. 그 근원은 브라우저에서 이러한 앱을 별개의 '앱'으로 간주하지 않기 때문에 발생합니다. 따라서 이 방법은 권장되지 않습니다.
다음 섹션에서는 이러한 도전과제를 더 자세히 분석합니다. 별도의 출처를 사용할 수 없다면 어떻게 해야 하나요?
여러 개의 동일 출처 PWA의 과제
다음은 두 가지 동일 출처 접근 방식에 공통적인 몇 가지 실용적인 문제입니다.
- 저장소: 쿠키, 로컬 저장소, 모든 형태의 기기 로컬 저장소는 앱 간에 공유됩니다. 따라서 사용자가 한 앱의 로컬 데이터를 완전 삭제하기로 결정하면 출처에서 모든 데이터가 완전 삭제됩니다. 단일 앱에서는 이 과정이 불가능합니다. Chrome 및 일부 다른 브라우저에서는 앱 중 하나를 제거할 때 사용자에게 로컬 데이터를 완전 삭제하라는 메시지를 표시하며 이는 원본에 있는 다른 앱의 데이터에도 영향을 미칩니다. 또 다른 문제는 앱이 저장용량 할당량을 공유해야 하므로 둘 중 하나가 너무 많은 공간을 차지하면 다른 하나가 부정적인 영향을 받는다는 것입니다.
- 권한: 권한은 출처에 연결됩니다. 즉, 사용자가 하나의 앱에 권한을 부여하면 이 출처의 모든 앱에 동시에 적용됩니다. 여러 번 권한을 요청할 필요가 없는 좋은 일처럼 들릴 수도 있지만, 사용자가 한 앱에 대한 권한을 차단하면 다른 사용자가 해당 권한을 요청하거나 그 기능을 사용하지 못하게 됩니다.
- 사용자 설정: 설정도 출처별로 설정됩니다. 예를 들어 두 앱의 글꼴 크기가 다르고 사용자가 이 중 하나의 확대/축소만 조정하여 보정하려는 경우 다른 앱에도 설정을 적용하지 않으면 확대/축소가 불가능합니다.
이러한 문제로 인해 이 접근 방식을 장려하기가 어렵습니다. 그럼에도 불구하고 별도의 출처 사용 섹션에 설명된 대로 별도의 출처 (예: 하위 도메인)를 사용할 수 없는 경우, 제시된 두 가지 동일한 출처 옵션에서 겹치거나 중첩되는 경로보다는 겹치지 않는 경로를 사용하는 것이 좋습니다.
앞서 언급했듯이 이 섹션에서 설명하는 문제는 두 가지 동일 출처 접근 방식에 공통적으로 적용됩니다. 다음 섹션에서는 중복/중첩된 경로를 사용하는 것이 가장 권장되지 않는 전략인 이유를 자세히 알아봅니다.
중첩/중첩된 경로의 추가 문제
중첩/중첩된 경로 접근 방식의 추가적인 문제 (여기서 https://example.com/는 외부 앱이고 https://example.com/app/는 내부 앱임) 내부 앱의 모든 URL이 실제로 외부 앱과 내부 앱의 일부로 간주된다는 점입니다.
실제로는 다음과 같은 문제가 있습니다.
- 설치 프로모션: 사용자가 내부 앱 (예: 웹브라우저)을 방문하는 경우 외부 앱이 이미 사용자의 기기에 설치되어 있으면 브라우저에 설치 프로모션 배너가 표시되지 않고 BeforeInstallPrompt 이벤트는 트리거되지 않습니다. 브라우저에서 현재 페이지가 이미 설치된 앱에 속하는지 확인하고 확인한 후 해당되는 것으로 결론을 내리기 때문입니다. 해결 방법은 '바로가기 만들기' 브라우저 메뉴 옵션을 통해 내부 앱을 수동으로 설치하거나 외부 앱보다 먼저 내부 앱을 설치하는 것입니다.
- 알림 및 배지 API: 외부 앱은 설치되었지만 내부 앱은 설치되어 있지 않은 경우 내부 앱에서 발생하는 알림과 배지는 외부 앱 (설치된 앱의 가장 가까운 범위)으로 잘못 표시됩니다. 이 기능은 사용자의 기기에 두 앱이 모두 설치되어 있는 경우 제대로 작동합니다.
- 링크 캡처: 외부 앱은 내부 앱에 속하는 URL을 캡처할 수 있습니다. 외부 앱은 설치되어 있지만 내부 앱은 설치되지 않은 경우에 특히 그렇습니다. 마찬가지로 내부 앱에 연결되는 외부 앱 내의 링크는 외부 앱 범위 내에 있는 것으로 간주되므로 내부 앱에 캡처를 연결하지 않습니다. 또한 ChromeOS와 Android에서는 이러한 앱이 Play 스토어에 신뢰할 수 있는 웹 활동으로 추가되면 외부 앱이 모든 링크를 캡처합니다. 내부 앱이 설치되어 있어도 OS는 사용자에게 외부 앱에서 내부 앱을 열 수 있는 선택권을 제공합니다.
결론
이 도움말에서는 개발자가 동일한 도메인 내에서 서로 관련된 여러 개의 프로그레시브 웹 앱을 빌드하는 다양한 방법을 살펴보았습니다.
요약하면 독립적인 PWA를 호스팅하려면 다른 출처 (예: 하위 도메인 사용)를 사용하는 것이 좋습니다. 이러한 앱을 동일한 출처에서 호스팅하면 많은 문제가 발생합니다. 주된 이유는 브라우저에서 이러한 앱을 별개의 앱으로 완전히 고려하지 않기 때문입니다.
- 별도의 출처: 권장
- 동일한 출처, 겹치지 않는 경로: 권장하지 않음
- 동일한 출처, 중복/중첩된 경로: 적극 권장되지 않음
서로 겹치지 않는 경로 (예: https://example.com/app1/ 및 https://example.com/app2/)를 사용하여 서로 다른 출처를 사용할 수 없다면 https://example.com/(외부 앱의 경우) 및 https://example.com/app/ (내부 앱의 경우)과 같이 겹치거나 중첩된 경로를 사용하는 것이 좋습니다.
추가 리소스
기술 검토와 제안에 많은 감사를 드립니다. Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner, Darwin Huang
사진: 팀 Mossholder, Unsplash