인증 종속 항목 맞춤설정

모듈식으로 설계한 Firebase JS SDK를 사용하면 앱을 빌드하는 방법을 훨씬 더 효과적으로 제어할 수 있습니다. 이러한 유연성 덕분에 플랫폼에 대한 종속 항목을 맞춤설정하고 필요하지 않은 기능을 제거하여 번들 크기를 최적화할 수 있습니다.

인증 라이브러리를 초기화하는 방법에는 getAuth() 함수와 initializeAuth() 함수를 사용하는 두 가지 방법이 있습니다. 첫 번째 getAuth() 함수를 사용하는 방법에서는 인증 라이브러리가 제공하는 모든 기능을 활용하기 위해 앱에 필요한 모든 항목을 제공합니다. 단점은 앱에서 사용하지 않을 가능성이 있는 다량의 코드를 가져온다는 것입니다. 또한 대상 플랫폼에서 지원되지 않는 코드까지 가져오기 때문에 오류가 발생할 수 있습니다. 이러한 문제를 방지하려면 종속 항목 맵을 사용하는 initializeAuth() 함수를 사용하면 됩니다. getAuth() 함수는 지정된 모든 종속 항목과 함께 initializeAuth()를 호출합니다. 설명을 위해 아래에는 브라우저 환경에서 getAuth()와 동등한 코드가 나와 있습니다.

import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, browserSessionPersistence, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: [indexedDBLocalPersistence, browserLocalPersistence, browserSessionPersistence],
  popupRedirectResolver: browserPopupRedirectResolver,
});

종속 항목 맞춤설정

일부 앱에서는 signInWithPopup 또는 signInWithRedirect 함수 계열을 사용하지 않습니다. 대다수의 앱은 indexedDB가 제공하는 유연성이 필요하지 않거나, indexedDB 및 localStorage 중 하나를 사용할 수 없는 경우에 둘 다 지원할 필요가 없게 됩니다. 이러한 경우 기본 getAuth()에 이유 없이 번들 크기를 늘리는 미사용 코드가 다량으로 포함됩니다. 이러한 앱에서는 대신 종속 항목을 맞춤설정할 수 있습니다. 예를 들어 앱에서 이메일 링크 인증만 사용하고 있으며 웹 또는 서비스 워커 스크립트를 사용하지 않기 때문에 localStorage면 충분하다면 다음과 같이 인증을 초기화하여 다량의 코드 블로트를 제거할 수 있습니다.

import {initializeAuth, browserLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: browserLocalPersistence,
  // No popupRedirectResolver defined
});

이 코드로 앱에 필요하지 않은 대용량 종속 항목 3개를 삭제하면 사용자가 사이트를 방문할 때마다 사용하는 대역폭의 양이 크게 줄어듭니다.

플랫폼별 고려사항

대부분의 경우 초기화 오류를 피하려면 인증 종속 항목을 수동으로 정의해야 합니다. getAuth() 함수는 특정 플랫폼을 사용한다고 가정합니다. 기본 진입점은 브라우저 환경이고 Cordova 진입점은 Cordova 환경입니다. 하지만 특정 애플리케이션의 경우 니즈에 따라 이러한 가정이 맞지 않을 수도 있습니다. 예를 들어 웹 및 서비스 워커 스크립트의 경우 기본 getAuth() 구현은 window 객체에서 읽은 코드를 가져오며, 이로 인해 오류가 발생합니다. 이러한 경우 종속 항목을 맞춤설정해야 합니다. 다음 코드는 서비스 워커 컨텍스트에서 인증 라이브러리를 초기화하는 데 적합합니다.

import {initializeAuth, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: indexedDBLocalPersistence,
  // No popupRedirectResolver defined
});

이 코드는 워커 컨텍스트에서 사용할 수 있는 indexedDB 지속성으로 인증을 초기화하도록 지시하며, popupRedirectResolver 종속 항목을 생략하여 DOM 컨텍스트를 사용할 수 있다고 가정합니다.

특정 플랫폼에서 종속 항목을 직접 정의할 수 있는 그 밖의 이유도 있습니다. 인증 초기화의 popupRedirectResolver 필드를 정의하여 경우에 따라 라이브러리가 초기화에 관한 추가 작업을 수행합니다. 모바일 브라우저에서 라이브러리는 사전에 인증 도메인 iframe을 자동으로 엽니다. 이렇게 하면 대부분의 사용자에게 원활한 환경을 제공할 수 있지만 앱 시작 시점에 바로 추가 코드를 로드하여 성능에 영향을 줄 수 있습니다. initializeAuth()를 활용하고 필요한 함수에 browserPopupRedirectResolver 종속 항목을 수동으로 전달하면 이 동작을 방지할 수 있습니다.

import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, indexedDBLocalPersistence, signInWithRedirect, GoogleAuthProvider} from "firebase/auth";
import {initializeApp} from "firebase/app";

const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
  persistence: [indexedDBLocalPersistence, browserLocalPersistence],
});

// Later
signInWithRedirect(auth, new GoogleAuthProvider(), browserPopupRedirectResolver);

initializeAuth()의 종속 항목에 browserPopupRedirectResolver를 제공했다면 signInWithRedirect() 호출에 세 번째 매개변수가 필요하지 않았을 것입니다. 그러나 이 종속 항목을 signInWithRedirect() 호출로 직접 이동하면 초기화 초기에 성능 저하가 사라집니다. 종속 항목을 이동하면 장단점이 있지만, 중요한 것은 라이브러리를 수동으로 초기화하여 이러한 장단점을 취사 결정할 수 있다는 것입니다.

커스텀 초기화를 사용하는 경우

요약하면, 커스텀 초기화를 사용하면 앱의 인증 SDK 사용을 훨씬 더 세부적으로 제어할 수 있습니다. 표준 getAuth() 함수는 시작하는 데 유용하며 대부분의 사용 사례에 적합합니다. 대부분의 앱에는 getAuth()만 있으면 됩니다. 하지만 다음과 같은 여러 가지 이유로 수동 종속 항목 관리로 전환하고 싶거나 전환해야 하는 경우가 있습니다.

번들 크기와 로드 시간이 매우 중요한 앱의 경우 커스텀 인증 초기화로 데이터 크기를 줄일 수 있습니다. 또한 초기화 시간 대신 사용 시간으로 종속 항목을 이동하여 초기 로드 시간을 줄일 수 있습니다.
DOM 외의 컨텍스트(예: 웹 및 서비스 워커)에서 실행되는 코드의 경우 오류를 방지하기 위해 initializeAuth()를 사용해야 합니다.