開発環境のFirebaseを構築し、アプリケーション側を設定してきます。今回の目的として、ローカルでは開発環境のFirebaseに接続するようにし、本番では本番環境のFirebaseに接続するようにします。

実行環境によってFirebaseとの接続を切り替えるアプリケーション側の設定

CSR・SSRどちらでも利用したいものはpublicで、サーバーサイドのみ利用するものはprivateで環境変数をセットします。今回はSSGで、CSRでも利用するためにpublicで設定しています。

ここでは本番環境の値を定義しています。

・nuxt.config.ts

...

runtimeConfig: {
  public: {
    fbApiKey: 'xxxxxxxxxxxx',
    fbAuthDomain: 'xxxxxxxxxxxx',
    fbProjectId: 'xxxxxxxxxxxx',
    fbStorageBucket: 'xxxxxxxxxxxx',
    fbMessagingSenderId: 'xxxxxxxxxxxx',
    fbAppId: 'xxxxxxxxxxxx',
    fbMesurementId: 'xxxxxxxxxxxx'
  }
},

...

ローカル用の環境変数を用意して、そこに開発環境用のFirebase接続情報を定義しています。

NUXT_という接頭辞をつけると、ランタイム構成の環境変数を上書きできます。今回はpublic配下の環境変数を上書きするのNUXT_PUBLIC_の接頭辞をつけています。

・.env.local

NUXT_PUBLIC_FB_API_KEY=xxxxxxxxxxxx
NUXT_PUBLIC_FB_AUTH_DOMAIN=xxxxxxxxxxxx
NUXT_PUBLIC_FB_PROJECT_ID=xxxxxxxxxxxx
NUXT_PUBLIC_FB_STORAGE_BUCKET=xxxxxxxxxxxx
NUXT_PUBLIC_FB_MESSAGING_SENDER_ID=xxxxxxxxxxxx
NUXT_PUBLIC_FB_APP_ID=xxxxxxxxxxxx

最後にpackage.jsonの実行コマンドに–dotenvで.env.localを読み込むようにして完了です。こうすることで、.env.localの値が上書きされて、ローカル起動時にFirebaseの開発環境に接続して開発することができます。

・package.json

...

"scripts": {
  "dev": "nuxi dev --dotenv .env.local"
},

...

参考：

UseCase層でGoogle認証のロジックを実装する

流れとしてはFirebase AuthenticationでGoogle認証した後、DBにユーザー情報を問い合わせます。

ユーザー情報がなかったら新規登録としてユーザ登録します。ユーザーログイン認証完了後はmypageに遷移し、認証情報をstateに登録します。

async signInWithGoogle(auth: Auth) {
  const userWithGoogle: CredentialUser = await this.authGateway.signInWithGoogle(auth)
  const userAccount: UserAccount | null = await this.userGateway.getUserByUid(userWithGoogle.uid)

  if (userAccount) {
    this.toastPresenter.successToast(MESSAGES.AUTH.LOGIN_SUCCESS)
  } else {
    await this.userGateway.createUser(userWithGoogle)
    this.toastPresenter.successToast(MESSAGES.AUTH.REGISTER_SUCCESS)
  }
  await this.storeAuthState(userWithGoogle.uid)
  this.navigationPresenter.navigateTo('/mypage')
} catch(error: Error) {
  console.error('signInWithGoogle error: ', error);
  this.toastPresenter.errorToast(`${MESSAGES.UNEXPECTED_ERROR}: ${error.message}`)
}

private async storeAuthState(uid: string) {
  const authAccount = await this.userGateway.getUserByUid(uid)
  this.authPresenter.storeAuth(authAccount!)
}ち

ちなみにUseCaseのUTはこんな感じになりました。あと登録パターンなどのシナリオがいくつかあるといった感じです。

Clean Architecutureをベースにレイヤリングしているので、テストは書きやすかったです。

it('Google認証でログインすることができる', async () => {
  const auth = mock<Auth>();
    
  const signInWithGoogleMock = jest.fn()
  when(signInWithGoogleMock).calledWith(auth).mockReturnValueOnce(credentialUser)
  authGateway.signInWithGoogle = signInWithGoogleMock

  const getUserByUidMock = jest.fn()
  when(getUserByUidMock).calledWith(credentialUser.uid).mockReturnValueOnce(userAccount)
  userGateway.getUserByUid = getUserByUidMock

  const successToastMock = jest.fn()
  when(successToastMock).calledWith(MESSAGES.AUTH.LOGIN_SUCCESS)
  toastPresenter.successToast = successToastMock

  const navigateToMock = jest.fn()
  when(navigateToMock).calledWith('/mypage')
  navigationPresenter.navigateTo = navigateToMock

  await authUsecase.signInWithGoogle(auth);

  expect(authGateway.signInWithGoogle).nthCalledWith(1, auth);
  expect(userGateway.getUserByUid).nthCalledWith(1, credentialUser.uid);
  expect(toastPresenter.successToast).nthCalledWith(1, MESSAGES.AUTH.LOGIN_SUCCESS);
});

GatewayでDomainに変換する

UseCaseのthis.authGateway.signInWithGoogle(auth)でFirebase AuthenticationにGoogle認証しているところをピックアップして、Gatewayの実装を取り上げます。

Gatewayとしては、DriverでサードパーティであるFirebase Authenticationを呼び出した返り値を、このアプリケーション内のコアとなるDomainに変換してUseCaseに返します。

つまり、Gatewayが外部とアプリケーションの境界部分を担っている感じです。今回は、CredentialUserというDomainに変換して、UseCaseに返しています。

async signInWithGoogle(auth: Auth): Promise<CredentialUser> {
  const userCredentialWithGoogle = await this.authDriver.signInWithGoogle(auth)
  return {
    uid: userCredentialWithGoogle.user.uid,
    displayName: userCredentialWithGoogle.user.displayName,
    email: userCredentialWithGoogle.user.email,
    photoURL: userCredentialWithGoogle.user.photoURL,
  } as CredentialUser
}

Driverで実際にGoogle認証する

実際にGoogle認証するのはこのDriverになります。DriverではGoogleAuthProvider()からsignInWithPopup()を呼び出し、認証した結果を返します。

本来はDriverで使用するエンティティを用意して、その型に詰めてからGatewayに返してあげる方が、アプリケーションとサードパーティとの切り分けができてより良い気もしますが、一旦ここではそのままGatewayに返しています。

async signInWithGoogle(auth: Auth): Promise<UserCredential> {
  const provider = new GoogleAuthProvider()
  const userCredentialWithGoogle = await signInWithPopup(auth, provider)
  return userCredentialWithGoogle
}

すんごいざっくりですが、メモ的な感じでまとめました。

NetlifyからFirebase Hostingに移行し、金額的にもNetlifyより安く抑えられてていい感じだったのですが、最近確認したら、送信バイト数が異常に上がっていることに気づきました。

真っ先に疑ったのが画像でした。と言っても新しく画像を急激に増やしたわけでも高画質にしたわけでもないので、うーんと思いながら調査しました。

画像はContentfulから持ってきているのですが、webpに変換していることもあり、やはりここまでの影響を与えていることはなさそうでした。

次に、このタイミングで認証機能をリリースしたこともあり、その機能にまつわる諸々洗い出していたのですが、さすがにこんなにも急激に送信バイトが増えるものは見当たらず途方に暮れていました。。

フォントでした

当たりが見当たらず、いろんなページを地道にネットワークで調べていたら、こんなにを見つけました。

異常なまでのサイズのデカさのフォントで、明らかに原因となっていそうです。完全にミスですが、フォントをダウンロードする形でFirebase Hostingに格納しており、毎通信でとてつもない転送量になっていました。

といわけで、このフォントを使わないようにして削除してデプロイしたら、案の定、収まりましたとさ。

めでたしめでたし。

今のざっくりアーキテクチャ図

こちらの記事で書いてありますが、元々Netlifyを使用していましたが、Firebase Hostingに移行しました。

NetlifyからFirebase Hostingに移行した話

満を辞して？NetlifyからFirebase Hostingに移行したので、メ…

mintaku-blog.net

基本SSGの構成は変わっておらず、後で説明しますが、一部SPA的なページが追加されました。

流れとしてはmainブランチにプッシュされるとGithub Actionsのパイプラインが動き出し、ビルドが始まります。

ビルド時はContenfulからデータを取得して、静的なページを生成していきます。ページの生成が完了すると、Firebase Hostingにデプロイします。

ページ数は今のところ大体3300ページくらいあり、ビルドしてデプロイするまで20分近くかかっており、長すぎるビルド時間が直近の課題となっています。

今考えているアプローチ方法は、ISGの導入や最近Nuxt3機能追加されたpayloadを使うなど、サーバー通信を減らしていきたいと思っています。

認証機能のところ

今回新しく追加した認証機能はFirebase Authenticationを使いました。Firebaseに統合したいのもあって、ホスティングサービスもNetlifyからFirebase Hostingに移行した感じです。

1stリリースでは、認証のプロバイダはGoogleとTwitterのみにしています。後々、メールアドレスや他のSNS認証も追加する予定です。

ユーザー情報などの格納データはFirestoreを使っています。Firebase Authenticationとあわせて開発しやすかったです。

今後のアーキテクチャについて

今後の開発において、ますます動的な機能が増えていくと思います。今はサーバーレスのSSGで開発していますが、後々はAPIを立てたり、SSRに変更するなど考えています。

新しい技術なども出てきたりすると思うので、臨機応変にその時その時考えて、アーキテクチャや使用技術を決めていきたいと思います。

また、負債を残さないためにもdependabotの導入によるライブラリのバージョンアップやこまめなリファクタリングなど、開発生産性を高く保ちながらより良いサービスを提供していきたいです。

なぜNetlifyからFirebase Hostingに移行したのか

Firebaseに集約したい

最近認証機能を実装したことから、Firebase AuthenticationやFirestoreを利用することになり、ホスティングサービスもFirebaseにまとめたい感がありました。

今後もFirebaseのサービスを使っていきたいと考えていたので、早いタイミングで集約していこうと思いました。

コストが安くなる

Netlifyの1ヶ月のビルド時間の無料枠は300分で、追加500分ごとに7ドルという料金体系でした。

最初は無料枠でも問題なくビルドできていましたが、コンテンツが増えて無料枠で収まることがなくなり、毎月追加枠を2つ購入していた感じになっていました。

そもそもビルド時間長すぎ問題があり、そちらも解決する必要があるのですが、今後もコンテンツが増えていくことを考えると地味にコストが効いてくるなと思っていました。

そこで色々調べていくとFirebase HostingとGitHub Actionsを組みわせた場合、無料枠は2000分とコストがかからずビルドできることを知り、移行したいと思う大きな要因となりました。

CDNのエッジが国内にあるので早くなるのでは

Netlifyの無料プランだと日本のエッジノードが利用できず海外からの配信になっているようで、Page Speed Insightsでチェックすると結構遅いことがわかりました。

Firebase Hostingなら国内からの配信になるようなので、サイトのパフォーマンスも向上すると考えていました。

NetlifyからFirebase Hostingへの移行作業

ローカルからFirebase Hostingにデプロイできるようにする

まずは公式を参考にして、ローカルでgenerateしたファイルをFirebase Hostingにデプロイできるようにしました。

デプロイしてみてFirebase Hostingにデフォルトで使われているドメインにアクセスしてみて、ページに問題ないかを確認しました。

GitHub Actionsでパイプラインを構築する

パイプラインを構築するといってもfirebase initするといい感じのymlファイルを生成してくれるので、それを元にちょっと変更しただけでした。

出来上がったパイプラインのymlファイルはこんな感じになりました。ちなみにworkflow_dispatchを追加するとGitHub Actionsから手動でトリガーできるようになります。

特にソースコード変更せずにコンテンツの更新などでビルドしたい場合に役立ちます。

name: Deploy to Firebase Hosting on merge
'on':
  push:
    branches:
      - main
  workflow_dispatch:
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm i && npm run generate
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_HOGE }}'
          channelId: live
          projectId: hoge

Firebase Hostingにドメインを設定する

この時点でGitHubにPushするとNetlifyとFirebase Hosting両方にデプロイされるようになっている状態です。

あとは独自ドメインをFirebase Hostingの方に設定するだけです。これも公式を元にポチポチ設定していけば完了します。

設定してから反映まで数時間かかったので、移行日が決まっている場合は、あらかじめ考慮しておくと良いでしょう。

NetlifyからFirebase Hostingに移行する際に注意すること

完全に忘れていたのですが、NetlifyはURLのパスを大文字から小文字に自動で変換していました。

ヘッドレスCMSとしてContentfulを使用しているのですが、そこのIDは自動で大文字小文字などが混ざった文字列を生成しており、それをURLのパスとして利用していました。

そのため、Google検索などからアクセスした際にURLのパスが小文字に変換された文字列になっており、Firebase Hostingに移行した際にFirebaseは小文字変換はしないため、存在しないページとして認識されてしまっていました。

リダイレクト処理する

ということで急いで対応しなければならず、一旦Netlifyに切り戻しを行いつつ、対策を考えました。

パッと思いついたのは小文字のパスでアクセスされた際にちゃんと元々の大文字が含まれたパスにリダイレクトする処理を入れることを思いつきました。

ビルドしているログには大文字が含まれたパスで生成されているのが確認できたので、それらを元にサクッとPythonでいい感じにFirebase.jsonのredirectsにそのままそのまま貼っつけられるような処理を書きました。

url_list = [ここに元々のURLを書く]

mappings = []

for url in url_list:
  source = url.lower()
  destination = url
  mappings.append({
    "source": source,
    "destination": destination,
    "type": 301
  })

print(mappings)

printした結果をfirebase.jsonに貼ってPushしてなんとかことなきを得ました。

NetlifyからFirebase Hostingに移行する際に結構ありがちな失敗かと思うので、参考になればと思います。

Firebaseの初期化の設定などはここでは省略します。今回はGoogleアカウントでの認証を例にメモ的な感じでまとめています。

実装としてはGoogleアカウントで認証し、登録情報をFirestoreに登録するといった流れです。

NuxtとFirebaseのバージョンは以下の通りです。

• Nuxt: 3.0.0
• Firebase: 9.15.0

Googleアカウントで認証する

Googleアカウントで登録する流れを実装していきます。

まずは登録するための画面をcomponentsに作成します。このコンポーネントはpagesで呼び出すイメージです。

「Googleで登録」のボタンを押下するとgoogleSignUpメソッドが呼び出されます。ここでのuseAuth()とgoogleSignUpメソッドは後ほど実装していきます。

・components/SignUpForm.vue

<template>
  <div class="signup-form">
    <p class="title">SNSアカウントで登録</p>
    <ul class="signup-buttons">
      <li><button class="google-button" @click="googleSignUp"><i><GoogleLogo></GoogleLogo></i><span>Googleで登録</span></button></li>
    </ul>
  </div>
</template>
 
<script setup lang="ts">
  import GoogleLogo from '@/assets/svg/icons/google-logo.svg'
  const googleSignUp = () => {
    const { googleSignUp } = useAuth()
    googleSignUp()
  }
</script>

「Googleで登録」のボタンを押下したgoogleSignUpメソッドがここで呼ばれます。GoogleAuthProviderのインスタンスを作成し、signInWithPopupを呼び出すことで、Google認証にポップアップが表示されます。

Google認証が完了したら、そのデータを元にgetUserメソッドでFirestoreのデータを取得しにいきます。

既にFirestoreにデータがある場合は、認証完了済みなのでログイン画面に遷移させます。データがない場合は新規登録なので、新しくFirestoreにuserデータを登録し、mypage画面に遷移させます。

最後にupdateUserメソッドを呼び出し、useState() を使ってuserの状態管理をしています。alertのところはいい感じのポップアップかトーストを実装したいところです。

・composables/useAuth.ts

import {
  Auth,
  User,
  UserCredential,
  onAuthStateChanged,
  signInWithPopup,
  GoogleAuthProvider,
} from "firebase/auth";
import { computed, ref } from "vue";
import {
  collection,
  where,
  query,
  getDocs,
  addDoc
} from '@firebase/firestore';
 
export function useAuth() {
  const { $auth, $firestore } = useNuxtApp()
  const user = ref<User | null>($auth.currentUser);
  const isAuthed = computed(() => !!user.value);
  const db = $firestore;
 
  $auth.onIdTokenChanged((authUser) => (user.value = authUser));
 
  // ユーザー情報取得
  const getUser = async (uid: string): Promise<any> => {
    const q = query(
      collection(db, 'users'),
      where("uid", "==", uid)
    );
    const querySnapshot = await getDocs(q);
 
    return querySnapshot.docs[0]
  };
 
  // ユーザー作成
  const createUser = async (user: UserCredential) => {
    await addDoc(collection(db, 'users'), {
      uid: user.user.uid,
      name: user.user.displayName,
      email: user.user.email,
      photo: user.user.photoURL
    })
  };
 
  // Google新規登録
  async function googleSignUp() {
    try {
      const provider = new GoogleAuthProvider();
      const googleUser = await signInWithPopup($auth, provider);
      const user = await getUser(googleUser.user.uid)
      const { updateUser } = await useUser()
      if (user) {
        alert("既にユーザー登録されています。")
        updateUser(user.data())
        navigateTo("/login", { replace: true })
      } else {
        alert("新規登録完了しました")
        await createUser(googleUser)
        const user = await getUser(googleUser.user.uid)
        updateUser(user.data())
        navigateTo("/mypage", { replace: true })
      }
    } catch (error) {
      throw error;
    }
  }
 
  async function currentUser() {
    return $auth.currentUser
  }
 
  return { isAuthed, user, checkAuthState, googleSignUp, currentUser };
}

updateUserメソッドを使ってuserのstateの状態を管理しています。

認証後はuserのstateにUser情報を入れ、ログアウトなどの認証情報が破棄された場合はnullを入れます。

・composables/useUser.ts

import { User } from "firebase/auth"
import { Ref } from "vue"

export const useUser = () => {
  const user: Ref<User | null> = useState<User | null>('user')

  const updateUser = (user: Ref<User | null>) => (value: User | null) => {
    user.value = value
  }

  return {
    user: readonly(user),
    updateUser: updateUser(user)
  }
}

認証状態のチェック

認証後のマイページに認証されていない場合はアクセスできないようにしたい場合、認証状態をチェックするなどの処理が必要になります。

その場合はmiddlewareで認証状態をチェックし、認証されていない場合はログインページに遷移させるなどの処理を実装します。

definePageMetaで指定してあげることで、このmiddlewareの処理が実行されます。

また、ログイン済みの場合にログインページを表示する場合は、マイページに遷移させるなどの処理も必要になるかと思います。

・middleware/auth.global.ts

export default defineNuxtRouteMiddleware(async () => {
  if (!process.server) {
    const { isAuthed, checkAuthState } = useAuth();
    await checkAuthState();

    if (!isAuthed.value) {
      window.location.href = "/login";
    }
  }
});

全てのルートで実行したい処理がある場合は、Nuxt3のグローバルミドルウェアを使うことで実現できます。

.globalが付いたファイルは呼び出し処理を書かずに全てのルートで実行されます。

・middleware/auth-check.global.ts

export default defineNuxtRouteMiddleware(async () => {
  if (!process.server) {
    const { checkAuthState } = useAuth();
    await checkAuthState();
  }
})

事前準備

認証をする前にfirebase.jsに以下の設定を書いて、Firebaseプロジェクトと連携しておきます。

・firebase.js

import firebase from 'firebase';

// Firebaseプロジェクトの設定
if (!firebase.apps.length) {
  firebase.initializeApp({
    apiKey: '{ウェブAPIキー}',
    authDomain: '{プロジェクトID}.firebaseapp.com',
    databaseURL: 'https://{プロジェクトID}.firebaseio.com',
    projectId: '{プロジェクトID}',
    storageBucket: '{プロジェクトID}.appspot.com',
    messagingSenderId: '1234567890' // cloudmessagingを使う場合は設定
  })
}

export const firestore = firebase.firestore();
export const storage = firebase.storage();

Google認証全体像

Firebase Authenticationを使ったGoogle認証の全体像は以下のようになります。こちらのコードは以下を参考にしています。

参考：https://github.com/FujiyamaYuta/nuxt-firebase-project

それぞれの処理をより深く理解するために、1つ1つの処理を追って自分の言葉で解説していきます。

<template>
  <b-modal :active.sync="isLoginModalActive" :width="420" scroll="keep">
    <div class="card">
      <div class="card-content">
        <div class="media">
          <div class="media-left"></div>
          <div class="media-content">
            <p class="title is-4">新規登録/ログイン</p>
          </div>
        </div>
        <div class="content">
          <button
            class="button sosial-button is-medium is-info is-fullwidth"
            style="background-color:white;color:red;border:2px solid; border-color:red;"
            @click="google"
          >
            <span class="icon">
              <i class="fab fa-google"></i>
              &nbsp;
              <span>Google</span>
            </span>
          </button>
        </div>
      </div>
    </div>
  </b-modal>
</template>

<script>
import 'bulma/css/bulma.min.css'
import '@fortawesome/fontawesome-free/css/all.min.css'
import 'bulma-social/bin/bulma-social.min.css'

import firebase from 'firebase'
import { firestore, storage } from '~/plugins/firebase.js'

export default {
  data() {
    return {
      isLoginModalActive: false
    }
  },
  methods: {
    login() {
      this.isLoginModalActive = true
    },
    // Google認証を行う関数
    google() {
      // ② Google認証
      const auth = () => {
        return new Promise((resolve, reject) => {
          const authUI = new firebase.auth.GoogleAuthProvider()
          firebase
            .auth()
            .signInWithPopup(authUI)
            .then((result) => {
              resolve(result)
            })
            .catch((error) => {
              const errorCode = error.code
              const errorMessage = error.message
              const email = error.email
              const credential = error.credential
              reject(error)
            })
        })
      }

      // ③ 認証後のユーザー情報を取得してオブジェクト化
      const getAccountData = (result) => {
        return new Promise((resolve, reject) => {
          let userObject = {}
          let user = result.user
          userObject.token = result.credential.accessToken
          userObject.refreshToken = user.refreshToken
          userObject.uid = user.uid
          userObject.displayName = user.displayName
          userObject.photoURL = user.photoURL
          userObject.uid = user.uid
          userObject.email = user.email
          userObject.isNewUser = result.additionalUserInfo.isNewUser
          userObject.providerId = result.additionalUserInfo.providerId
          resolve(userObject)
        })
      }

      // 同期的に順番に処理を実行する
      Promise.resolve()
        .then(this.setPersistence)
        .then(auth)
        .then(getAccountData)
        .then((userObject) => this.createPhotoURL(userObject))
        .then((userObject) => this.setPublicUserData(userObject))
        .then((userObject) => this.setPrivateUserData(userObject))
        .then((userObject) => this.setLocalUserData(userObject))
        .catch((error) => this.onRejectted(error))
    },
    onRejectted(error) {
      this.$buefy.toast.open({
        duration: 5000,
        message: `ログインに失敗しました。`,
        position: 'is-bottom',
        type: 'is-danger'
      })
      this.isLoginModalActive = false
    },
    createPublicObj(obj) {
      let publicObj = {}
      publicObj.uid = obj.uid
      publicObj.providerId = obj.providerId
      publicObj.isNewUser = obj.isNewUser
      publicObj.photoURL = obj.photoURL
      publicObj.displayName = obj.displayName

      return publicObj
    },
    createPrivateObj(obj) {
      let privateObj = {}
      privateObj.uid = obj.uid
      privateObj.providerId = obj.providerId
      privateObj.isNewUser = obj.isNewUser
      privateObj.email = obj.email
      privateObj.token = obj.token
      privateObj.refreshToken = obj.refreshToken
      return privateObj
    },
    // ① 認証状態を明示的にセットする
    setPersistence() {
      return new Promise((resolve, reject) => {
        firebase
          .auth()
          .setPersistence(firebase.auth.Auth.Persistence.LOCAL)
          .then((result) => {
            resolve()
          })
      })
    },
    // ⑤ 公開可能なユーザー情報をFirestoreに登録
    setPublicUserData(userObject) {
      return new Promise((resolve, reject) => {
        let publicUser = firestore.collection('users').doc(userObject.uid)
        // ** usersに登録するObjのみを登録する
        publicUser
          .set(this.createPublicObj(userObject), { merge: true })
          .then((result) => {
            resolve(userObject)
          })
      })
    },
    // ⑥ 非公開のユーザー情報をFirestoreに登録
    setPrivateUserData(userObject) {
      return new Promise((resolve, reject) => {
        let privateUsers = firestore
          .collection('privateUsers')
          .doc(userObject.uid)
        // privateUsersに登録するObjのみを登録する
        privateUsers
          .set(this.createPrivateObj(userObject), { merge: true })
          .then((result) => {
            resolve(userObject)
          })
      })
    },
    // ⑦ ローカルストレージに保持するユーザー情報を設定
    setLocalUserData(userObject) {
      return new Promise((resolve, reject) => {
        let user = firestore.collection('users').doc(userObject.uid)
        user
          .get()
          .then((doc) => {
            if (doc.exists) {
              localStorage.setItem('photoURL', doc.data().photoURL)
              localStorage.setItem('uid', userObject.uid)
              localStorage.setItem('token', userObject.token)
              localStorage.setItem('displayName', doc.data().displayName)
              this.$buefy.toast.open({
                duration: 5000,
                message: `ログインに成功しました`,
                position: 'is-bottom',
                type: 'is-success'
              })
              this.isLoginModalActive = false
              location.reload()
              resolve(userObject)
            }
          })
          .catch((error) => {
            console.log('ログインに失敗しました。Error getting document:', error)
          })
      })
    },
    // ④ 取得したアイコンのURLをFirestorageに保存して、そのURLをFirestoreに登録する準備
    createPhotoURL(userObject) {
      return new Promise((resolve, reject) => {
        let url = userObject.photoURL
        let xhr = new XMLHttpRequest()
        xhr.responseType = 'blob'
        xhr.onload = function(event) {
          let blob = xhr.response
          let storageRef = storage.ref()
          let mountainsRef = storageRef.child(
            `user/${userObject.uid}/image.jpg`
          )
          let uploadTask = mountainsRef.put(blob)
          uploadTask.then((snapshot) => {
            uploadTask.snapshot.ref.getDownloadURL().then((downloadURL) => {
              console.log(downloadURL)
              // firestorageに登録したURLを登録するオブジェクトに代入
              userObject.photoURL = downloadURL
              resolve(userObject)
            })
          })
        }
        // メッセージを受け取った後に返信する
        xhr.open('GET', url)
        xhr.send()
      })
    }
  }
}
</script>
<style>
  .sosial-button {
    margin-top: 1rem;
  }
</style>

ユーザー認証の処理を順番に実行

メソッドチェーンで順番に処理を実行していきます。

then内のいずれかでエラー(reject)が発生した場合にonRejecttedメソッドが呼び出されます。

Promise.resolve() メソッドは、引数の値でPromiseオブジェクトを返します。その値がプロミスであった場合は、そのプロミスが返されます。その値がthenable (すなわちthenメソッドを持っている場合) であれば、返されるプロミスは thenable を追跡し、その最終的な状態になります。

今回の場合は返り値がなくその後の処理もないため、①から⑦まで順番に実行して終了します。

// 順番に処理を実行する
Promise.resolve()
  .then(this.setPersistence) // ①
  .then(auth) // ②
  .then(getAccountData) // ③
  .then((userObject) => this.createPhotoURL(userObject)) // ④
  .then((userObject) => this.setPublicUserData(userObject)) // ⑤
  .then((userObject) => this.setPrivateUserData(userObject)) // ⑥
  .then((userObject) => this.setLocalUserData(userObject)) // ⑦
  .catch((error) => this.onRejectted(error))

① 認証状態の永続性をセット

setPersistenceメソッドで認証状態の永続性をセットします。

認証状態の永続性のタイプは「local」、「session」、「none」の３つがあります。詳しい説明などはこちらの公式サイトを参照ください。

認証状態の永続性は、firebase.auth().setPersistence メソッドを呼び出すことによって指定または変更できます。

// ① 認証状態の永続性をセットする
setPersistence() {
  return new Promise((resolve, reject) => {
    firebase
      .auth()
      .setPersistence(firebase.auth.Auth.Persistence.LOCAL)
      .then((result) => {
       resolve()
      })
  })
},

② Google認証

Googleの認証を行います。

firebase.auth.GoogleAuthProvider()メソッドでGoogle認証のプロバイドを呼び出します。それを引数に firebase.auth().signInWithPopup()メソッドで認証画面のポップアップを表示します。

Google認証完了後、認証の結果のプロミスを返します。エラーコードやエラーメッセージなどはcatch内の方法で取得できるため、Google認証に失敗した時のエラーハンドリングで使うことができます。

// ② Google認証
const auth = () => {
  return new Promise((resolve, reject) => {
    const authUI = new firebase.auth.GoogleAuthProvider()
    firebase
      .auth()
      .signInWithPopup(authUI)
      .then((result) => {
       resolve(result)
      })
      .catch((error) => {
        const errorCode = error.code
        const errorMessage = error.message
        const email = error.email
        const credential = error.credential
        reject(error)
      })
  })
}

③ ユーザー情報を取得し、オブジェクト化

Google認証の結果を元にユーザー情報を取得して、オブジェクト化します。オブジェクト化した結果のプロミスを返します。

// ③ 認証後のユーザー情報を取得してオブジェクト化
const getAccountData = (result) => {
  return new Promise((resolve, reject) => {
    let userObject = {}
    let user = result.user
    userObject.token = result.credential.accessToken
    userObject.refreshToken = user.refreshToken
    userObject.uid = user.uid
    userObject.displayName = user.displayName
    userObject.photoURL = user.photoURL
    userObject.uid = user.uid
    userObject.email = user.email
    userObject.isNewUser = result.additionalUserInfo.isNewUser
    userObject.providerId = result.additionalUserInfo.providerId
    resolve(userObject)
  })
}

④ アイコン画像をFirestorageに保存し、そのパスを取得

GoogleのアイコンのURLからXMLHttpRequestでアイコン画像を取得します。

xhr.responseTypeでレスポンスの方をblobに定義しています。let blob = xhr.responseで取得した画像のblobオブジェクトをblobに渡しています。

その後、Storageのuser/${userObject.uid}/image.jpgパスを用意し、そこにアイコン画像データを保存します。

getDownloadURL()メソッドで、保存したアイコン画像のURLパスを取得し、userObject.photoURLに渡しています。

つまりGoogle認証時に取得したGoogle内に保持しているアイコン画像のパスからXMLHttpRequestでアイコン画像をblobタイプで取得し、それをFirestorageに保存し、保存したURLのパスを取得しFirestoreに保存するために再度userObject.photoURLにパスを渡しているといった処理になります。

xhr.send()の処理は、「Unchecked runtime.lastError: The message port closed before a response was received.」のエラーを回避するため、特に何もなくても返信しています。

参考：https://qiita.com/noenture/items/3978f638f2ffb8ff0995

// ④ 取得したアイコンのURLをFirestorageに保存して、そのURLをFirestoreに登録する準備
createPhotoURL(userObject) {
  return new Promise((resolve, reject) => {
    let url = userObject.photoURL
    let xhr = new XMLHttpRequest()
    xhr.responseType = 'blob'
    xhr.onload = function(event) {
      let blob = xhr.response
      let storageRef = storage.ref()
      let mountainsRef = storageRef.child(
        `user/${userObject.uid}/image.jpg`
      )
      let uploadTask = mountainsRef.put(blob)
      uploadTask.then((snapshot) => {
        uploadTask.snapshot.ref.getDownloadURL().then((downloadURL) => {
          // Firestorageに登録したURLを登録するオブジェクトに代入
          userObject.photoURL = downloadURL
          resolve(userObject)
        })
      })
    }
    // メッセージを受け取った後に返信する
    xhr.open('GET', url)
    xhr.send()
  })
}

⑤ 公開可能なユーザー情報をFirestoreに登録

ユーザー情報の中でも公開可能な情報をFirestoreに登録します。createPublicObjメソッドを呼び出しpublicObjに公開可能な情報をセットし、Firestoreのusersコレクション内にuidをkeyにして登録しています。

mergeオプションをつけるとフィールドの追加をしています。

// ⑤ 公開可能なユーザー情報をFirestoreに登録
setPublicUserData(userObject) {
  return new Promise((resolve, reject) => {
    let publicUser = firestore.collection('users').doc(userObject.uid)
    // usersに登録するObjのみを登録する
    publicUser
      .set(this.createPublicObj(userObject), { merge: true })
      .then((result) => {
        resolve(userObject)
      })
  })
},

createPublicObj(obj) {
  let publicObj = {}
  publicObj.uid = obj.uid
  publicObj.providerId = obj.providerId
  publicObj.isNewUser = obj.isNewUser
  publicObj.photoURL = obj.photoURL
  publicObj.displayName = obj.displayName

  return publicObj
},

⑥ 非公開なユーザー情報をFirestoreに登録

公開可能のユーザ情報登録と同じように、非公開のユーザ情報も登録していきます。非公開情報ではメールやトークンが登録されています。

// ⑥ 非公開のユーザー情報をFirestoreに登録
setPrivateUserData(userObject) {
  return new Promise((resolve, reject) => {
    let privateUsers = firestore
      .collection('privateUsers')
      .doc(userObject.uid)
    // privateUsersに登録するObjのみを登録する
    privateUsers
      .set(this.createPrivateObj(userObject), { merge: true })
      .then((result) => {
        resolve(userObject)
      })
  })
},

createPrivateObj(obj) {
  let privateObj = {}
  privateObj.uid = obj.uid
  privateObj.providerId = obj.providerId
  privateObj.isNewUser = obj.isNewUser
  privateObj.email = obj.email
  privateObj.token = obj.token
  privateObj.refreshToken = obj.refreshToken
  return privateObj
},

⑦ ローカルストレージに保持するユーザー情報をセット

Firestoreに保存した公開可能なユーザ情報から「アイコン画像パス」、「uid」、「トークン」、「表示名」を取得し、Local Storageにセットして、認証完了です。

ユーザーがログイン状態になり、更新情報を画面に反映させるためにリロードしています。

// ⑦ ローカルストレージに保持するユーザー情報を設定
setLocalUserData(userObject) {
  return new Promise((resolve, reject) => {
    let user = firestore.collection('users').doc(userObject.uid)
    user
      .get()
      .then((doc) => {
        if (doc.exists) {
          localStorage.setItem('photoURL', doc.data().photoURL)
          localStorage.setItem('uid', userObject.uid)
          localStorage.setItem('token', userObject.token)
          localStorage.setItem('displayName', doc.data().displayName)
          this.$buefy.toast.open({
            duration: 5000,
            message: `ログインに成功しました`,
            position: 'is-bottom',
            type: 'is-success'
          })
          this.isLoginModalActive = false
          location.reload()
          resolve(userObject)
        }
      })
      .catch((error) => {
        console.log(error)
    })
  })
},

エラーハンドリング

ユーザー認証のメソッドチェーン内でエラーが発生した場合は、catch内のonRejecttedメソッドが呼び出され、ログインに失敗するようハンドリングしています。

onRejectted(error) {
  this.$buefy.toast.open({
    duration: 5000,
    message: `ログインに失敗しました。`,
    position: 'is-bottom',
    type: 'is-danger'
  })
  this.isLoginModalActive = false
},

参考：
https://github.com/FujiyamaYuta/nuxt-firebase-project
https://developer.mozilla.org/ja/docs/Web/API/XMLHttpRequest
https://qiita.com/ueokande/items/807a6c9a64c3874a0f83
https://qiita.com/toshihirock/items/e49b66f8685a8510bd76
https://qiita.com/noenture/items/3978f638f2ffb8ff0995

Cloud Runに紐づけるドメインのリソースをデプロイ

事前に独自ドメインに紐づけるリソースをCloud Runにデプロイしておきます。デプロイすると上の画像のようにサービスが追加されていることが確認できます。

マッピングの追加

Cloud Runのカスタムドメインを管理からマッピングの追加を行います。

Cloud Runにデプロイした独自ドメインと紐付けたいリソースを選択し、紐づける独自ドメインを入力します。

ドメインの確認ができていない場合は、ウェブマスターセントラルに進んで確認を完了させます。

DNSレコードの更新

所有権の証明が完了したら、DNSレコードを更新します。表示されたDNSレコードをCloud DNSに登録します。

今回は既に設定する独自ドメインがFirebase Hostingに紐づいているため、そのDNSレコードを削除して登録します。このタイミングでFirebase Hostingされている既存のサイトが見れなくなるので注意が必要です。

大体15分ほど経つと、Cloud Runのリソースに設定した独自ドメインが紐づきます。

上の画像のようにCloud Runのサービス詳細画面のURLにあるカスタムドメインの欄に紐付けたいドメインが表示されていれば完了です。

Firebase Hostingの画面で独自ドメインの設定が解除されたか確認

Firebase Hostingの画面にアクセスすると、ドメインの紐付けが解除されており、「設定が必要です」となっているため、後は必要に応じてドメインを削除しましょう。

Nuxt.jsのアプリをコンテナ化し、Container Registryに登録し、Cloud Runにデプロイする方法

Cloud BuildとCloud Runの有効化

まずはCloud Build APIとCloud Run APIを有効化しておきます。

# Cloud Buildの有効化
$ gcloud services enable cloudbuild.googleapis.com

# Cloud Runの有効化
$ gcloud services enable run.googleapis.com

nuxt.config.jsの変更

nuxt.config.jsにserverオプションを追加します。

hostはlocalhostや127.0.0.1ではなく、0.0.0.0に設定する必要があります。

・nuxt.config.js

export default {
  server: {
    port: 3000, // default: 3000
    host: '0.0.0.0', // default: localhost,
    timing: false
  }
}

cloudbuild.yamlを作成する

cloudbuild.yamlの書き方は以下の公式サイトを参考にしています。

コンテナイメージをビルドして、Container Registryにプッシュしています。その後、Container RegistryからCloud Runにデプロイしています。

参考：

Cloud Build を使用した Cloud Run へのデプロイ  |  Google Cloud Documentation

cloud.google.com

・cloudbuild.yaml

steps:
  # Build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/test-staging/nuxt-ssr', '.']
  # Push the container image to Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/test-staging/nuxt-ssr']
  # Deploy container image to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: ['run', 'deploy', 'nuxt-ssr-test', '--image', 'gcr.io/test-staging/nuxt-ssr', '--region', 'asia-northeast1', '--platform', 'managed', '--port', '3000']
images:
  - gcr.io/test-staging/nuxt-ssr

Dockerfileを作成する

次にNuxt.jsのアプリをコンテナ化するためにDockerfileを作成します。

参考：

Nuxt 2 - Google Cloud Run

Nuxt を Google Cloud Run にどうやってデプロイするのか？

ja.nuxtjs.org

・Dockerfile

FROM node:14

# https://docs.docker.jp/engine/reference/builder.html#workdir
WORKDIR /usr/src/app

COPY package.json ./
RUN npm install

COPY . .

# https://docs.docker.jp/engine/reference/builder.html#expose
# EXPOSE 命令はコンテナの実行時に、所定ネットワーク上のどのポートをリッスンするかを指定
EXPOSE 3000

RUN npm run build

CMD [ "npm", "run", "start" ]

gcloud initした後に以下のコマンドでcloudbuild.yamlのコマンドが走ります。

$ gcloud builds submit

成功すると、Container Registryにコンテナイメージが登録され、Cloud Runにコンテナがデプロイされていることが確認できます。

・Container Registry

・Cloud Run

Cloud Runにデプロイしたリソースにメンバーとロールの追加

Cloud Runにデプロイしたままでは、デプロイしたアプリは誰もアクセスすることができません。

アクセスできるようにするために、Cloud Runにデプロイしたリソースにメンバーとロールを追加します。

ここでは全てのユーザが見れるようにメンバーを「allUsers」にし、ロールを「Cloud Run起動元」で追加します。「allUsers」すると、デプロイしたリソースは一般公開され、インターネット上から誰でもアクセスできる状態になるため、注意していください。

保存後、Cloud Runに記載されているURLにアクセすることができるようになります。

Firebase HostingからCloud Runにリクエストをリダイレクトする

Firebase HostingでホスティングしたNuxt.jsプロジェクトを一部Cloud RunでSSRします。Cloud RunでSSRしたいリソースをfirebase.jsonのrewritesに追加します。

今回の場合は、/testsをCloud Runのリソースを使うようにします。つまり、/testsへのアクセスがあった場合にFirebase Hostingのリソースを使わずに、Cloud Runのリソースを使うようリクエストをリダイレクトします。

なおFirebase Hostingの/testsのリソースは空にしておかないと、正常にリダイレクトされないので注意しましょう。

serviceIdは先ほどデプロイしたCloud Runのサービス、regionはCloud Runで使用しているリージョンを選択します。後はfirebase.jsonをデプロイして完了です。

・firebase.json

...

  "rewrites": [
  {
    "source": "/tests",
    "run": {
      "serviceId": "nuxt-ssr-test",
      "region": "asia-northeast1"
    }
  }
],

...

Jamstack構成にあたり以下のサービスを活用しています。

• 静的サイトジェネレータ：Nuxt.js
• ヘッドレスCMS：microCMS
• ホスティングサービス：Firebase Hosting

Jamstackとは

Jamstack(ジャムスタック)とはウェブサイトを実現するためのJAMの頭文字からなる技術の組み合わせです。JAMはそれぞれJavaScript・API・ Markupを表しています。

Jamstackは、サーバとフロントを疎結合にし、サーバが担っていた機能を外部化してフロントだけで扱いやすくする構成となっています。

公式サイト：https://jamstack.org/

Jamstackの特徴

• Webサイトの各ページのHTMLファイルは事前に静的サイトジェネレータで生成
• ブラウザからアクセス時にCDNから配信
• Webサーバに依存しないサーバレスな構成

Jamstackは以上のような特徴が挙げられます。

閲覧専用でユーザごとにコンテンツの出し分けがないようなWebサービスに最も適していると考えられます。パッと思いつくのは、ユーザ認証等がないWebメディアやコーポレートサイトで効果を発揮しそうです。

Jamstackで使われるサービス

このようなJamstack構成を実現させるために、以下のようなサービスが使われます。

• 静的サイトジェネレータ
• ヘッドレスCMS
• ホスティングサービス

Jamstackアーキテクチャの採用にあたり今回開発した新規サービスでは、静的サイトジェネレータはNuxt.js、ヘッドレスCMSはmicroCMS、ホスティングサービスはFirebase Hostingを採用しています。

ホスティングサービスは他にNetlifyが有名(そもそもNetlifyのCEOがJamstack提唱したっぽい)で、そちらはWebhookによるトリガが可能(Firebase Hostingではできないっぽい？)なので、ヘッドレスCMSから記事投稿時にWebhookによる通知をして、自動ビルドできます。

Firebase Hostingでは調べた限りでは、Webhookによるトリガができないようなので、新規サービスではGitプッシュ時とスケジューリングで1日1回自動ビルドするように運用しています。どうしてもその日に公開したい記事の場合は手動でビルド・デプロイといった感じです。

Jamstack導入のメリット

Jamstackには以下のようメリットがあります。

・高パフォーマンス
→nuxt generateによってデプロイ前にあらかじめ静的ページを生成することでCDN配信が可能となり、より高いパフォーマンスを実現できました。

・高セキュリティ
→コンテンツ等はあらかじめ静的ファイルとしてホスティングしているため、サーバ側のプロセスが必要最低限のAPIに集約され、脆弱性に対する攻撃対象の減少が期待できます。

・コスト削減
→主にコンテンツ配信の手段として利用するため、コストの削減が可能となります。

・SEO向上
→SSGによるページ遷移の高速化・サーバ側でレンダリングしたHTMLを読み込むことにより、SEO向上が期待できます。

また、コンテンツにおけるAPIレスポンスは、ビルドのタイミングで全部取得してホスティングしているため、安定的な稼働が可能となります。

逆に言えば、ビルド時にAPIがおかしかったらエラーがでるため、デプロイ前に気づくことができるのも良い点かと思います。

Jamstack採用において

今回の新規サービスでは、認証機能やユーザ登録・更新処理などが追加実装されたため、完全なJamstack構成というより、部分的Jamstack構成になりました。

もし、認証機能やユーザ登録・更新処理などがなくコンテンツのみの場合は以下のような構成になります。

これが静的ファイルのみで構成される一般的なJamstack構成になると思います。Firebase HostingからCDN配信で完結しているため、サイトの高速化・高セキュリティ・サーバレスとなります。

なんとかヘッドレスCMSからの記事投稿をトリガに自動ビルド・デプロイできれば理想型って感じですかね。

実際の新規サービスでは認証機能等あるので、以下のような構成になります。

• コンテンツはあらかじめビルドしてある静的ファイルをFirebase HostingからCDN配信
• 認証はFirebase Authenticationを利用
• ユーザ登録やユーザ情報更新等は別途APIからやり取り

コンテンツの表示スピードの高速化やSEO向上、ユーザ情報登録・更新や検索のみサーバを使っているのでコストの削減もでき、Jamstackの恩恵を十分に受けられていると感じています。

まとめ

実際にJamstackアーキテクチャで新規サービスを開発してみて、サイトスピードが高速化し安定的に稼働していていい感じです。

毎回ビルドするといった手間はありますが、CI/CDツールを取り入れればそんな手間ではなくなります。

静的化できるファイルが多くある場合は、Jamstackアーキテクチャを取り入れるのが良さそうですね。