NextでFirebaseを使ってWebアプリを実装するコツは？

NextでFirebaseを使ってWebアプリを実装するコツは？

Next で Firebase を使って Web アプリを実装する場合、ちょっとした注意が必要です。大きな理由は、Firebase admin SDK は、Web ブラウザ内では動作しないようにできているからです。

Next で実装する場合、サーバー側で Firebase のデータベースなどにアクセスするケースが多いのですが、サーバー側で Firebase のデータベースにアクセスする場合は、Firebase admin SDK を使ってアクセスする必要があります。

ところが、この Firebase admin SDK を使って、Web ブラウザから Firebase のデータベースにアクセスしようとするとエラーになります。

サーバー側で HTMl ページを作る Next

一番のポイントは、Next の仕組みをよく理解して置くことにつきます！ 特に、記述したプログラムのコードがどこで実行されるかをきちんと理解しておく必要があります。

基本は、Next のアプリの場合、HTML のページはサーバー側が作っているということです。Web サイトの原理を考えれば当たり前なのですが、通常の静的なページ（HTML ファイルなど）はサーバーがリクエストに合わせて Web ブラウザに提供します。

また、事前に準備可能なページは Next の公開用のイメージをビルドした段階で作られています。つまり、Next がレンダリング（描画）していますが、予め表示に必要な情報は作られているという事になります。

動的なページは、ページがリクエストされた時にサーバー側で作って Web ブラウザに送られます。この時、表示に必要な情報は、サーバー側で取得して、サーバーが表示データを作る場合が殆どです。

ここで、ポイントとなるのは、Firebase のアクセスをどこで行うかという事です。 ページを作る時にデータを取得する場合、Firebase のアクセスはサーバー側で行うことになります。

ところが、Web ブラウザがページを読み込んだ後に、例えばボタンが押されたイベントの処理として、Firebase にアクセスする場合は、ちょっと複雑です。

ページは既に Web ブラウザに読み込まれているので、ボタンが押されたイベントの処理は基本的には Web ブラウザで行うことになります。

Web ブラウザでの処理方法は？

Web ブラウザでページの読み込みが完了した後に Firebase に Web ブラウザからアクセスする場合は、基本的に React のアプリから Firebase にアクセスする場合と同じ方法が利用できます。通常の Firebase のクライアントアクセスとしてアクセスすれば OK です。

別な方法は、サーバー側に Firebase のアクセスを任せる方法です。データは、バックエンドと API を決めてサーバー側で Firebase のデータを取得した後に、ネットワークを介してデータを受け取る方法が利用可能です。

もう一つの方法としては、クエリーパラメータなどでサーバーに欲しいデータを指定して新たなページを取得するという方法も使えます。

どの方法が良いかはアプリケーションによりますが、できれば、サーバー側か Web ブラウザ側かでアクセスを一本化した方が管理のしやすいコードになります。これは、開発時は良くても、後からコードを見る場合に、Firebase のアクセス方法がサーバー側と Web ブラウザ側で混在する場合、わかりにくい実装になりやすいからです。

どちらが便利か？

Next でアプリを開発する場合は、Firebase admin SDK を使った方が有利な場合が多くなります。理由はいくつかありますが、大きなものは以下のような理由です。

＊　セキュリティルールが不要

＊　データベースの実装を切り離せる

などです。Firebase admin SDK の場合は、セキュリティルールの設定にかかわらず全てのデータベースのデータにアクセスが可能です。アクセスの制限はバックエンドとのインターフェース（API）で決められます。API の決め方でアクセスできる範囲が決まるので、セキュリティルールとは違うレベルでの制限が可能になります。

例えば、データベースからのデータをそのまま Web ブラウザのフロントエンドに渡すのではなく、データベースのデータを読んで処理をして渡すということも可能になります。

もう一つは、データベースの構造などの実装をフロントエンドから独立して設計できるという利点があります。これにより、フロントエンドはどちらかというとユーザーインターフェースを中心とした実装にして、バックエンドで実際のデータ処理をするという感じで、実装を明確に分けることができます。

実際の処理をサーバー側にうつすと、データの処理の内容などが利用者からは「見えない」ようになるのでセキュリティ上も良い実装が可能です。

例えば、ブログの原稿を Markdown で書いて、その内容を HTML に変換して表示するアプリを作る場合、フロントエンドで処理した場合、フロントエンドで Marckdown のデータを受け取るので、技術的にはこの Markdown のデータを簡単に取得できます。 しかし、この処理をサーバー側（バックエンド）で処理をすると、変換したデータのみをフロントエンドに送れば良いので、Markdown のデータの取得は簡単にはできません。（Markdown のデータはブラウザには送られないため）

サーバー側で動く処理は？

Next の場合、各ページで必要なデータをページを作る前に取得したり処理する場合は、サーバー側でその処理をおこないます。こうした、処理の例は、「getServerSideProps()」の処理などです。この処理はページが呼ばれると最初に実行されて、その処理結果を「props」として、React のコンポーネントに渡す仕組みになっています。他にも、「getStaticProps（）」や「getStaticPaths()」なども、サーバー側のメソッドです。 静的な部分（Static）は Next のビルドの際は、予め静的ページの情報は作成してしまうので、実際の動作環境では呼ばれないメソッドですが、開発用のサーバ（npm run dev で起動した場合）は、サーバー側で実際に呼び出されて実行されます。

その後の処理は、Web ブラウザがページ情報を受け取って Web ブラウザが行うことになります。

それぞれの処理がどこでいつ実行されるかで、Firebase の利用の仕方が違います。サーバー側で動かす場合は、Firebase admin SDK を、Web ブラウザで動かす場合は、通常のクライアント版の Firebase を利用してアクセスします。

Next のアプリの開発で慣れるまで面倒なのは、実際のコードが「いつ」「どこで」実行されるかをきちんと理解する必要があるからです。これによって、.env(.env.＊)で定義できる環境変数も、利用できる場所が違っているのは同じ理由からです。通常の環境変数は、Web ブラウザでは認識されず、認識させるには「NEXT＿PUBLIX＿」を先頭につけて明示的に Web ブラウザで使うことを示す必要があります。

これは、環境変数で、バックエンドで使うシークレットキー（秘密鍵）を定義する場合があるためです。Web ブラウザでアクセス可能なファイルに重要な情報が入らないようにする措置です。

まとめ

サーバー側でレンダリング（描画）を行う、Next や Vue は便利なフレームワークですが、その実装には実際の Web サイトの動作をきちんと理解しておく必要があります。 何を、サーバーがやって、何を Web ブラウザがやっているかを理解しないと、実装が難しくなります。

処理をする場所によって色々な制限事項があったりするので、これを正しく理解して処理の内容を決めないとエラーになったり、セキュリティの問題が起きる可能性があるからです。

そう考えると、最初はフロントエンドを中心とした実装から始める方が問題が少ないので簡単です。