Next/Nuxt で作ったアプリもホスティングできる Firebase

Next/Nuxt で作ったアプリもホスティングできる Firebase

Web アプリをサーバーサイドのレンダリングを利用して実装するフレームワークは、Next や Nuxt がよく利用されますが、実際にインターネットに公開する場合はフロントエンドのフレームワークの React や Vue を利用した場合に比べると少し面倒なケースが多くなります。

理由は、当然と言えば当然ですが、サーバー側でバックエンドのプログラムを動かす必要があるのが大きな理由です。Firebase はバックエンドのサービスを Functions(Cloud Functions)という形でサポートしているので、Nuxt のアプリをホスティングすることもできます。

この記事では、まずは、Firebase で Nuxt のアプリをホスティングする仕組みについて概要を説明します。詳しいやり方は別の記事で改めて紹介する予定です。

サーバー側のレンダリングとは？

最初にまず「サーバー側のレンダリング」（Server Side Rendering/SSR）について簡単に説明します。

Web サイトの基本的な仕組みは、サーバーに HTML で書かれたファイルを置いておいて、Web ブラウザが URL を指定して表示するデータを受け取ることで実現しています。

シンプルなサイトの場合は、HTML ファイルに書かれた HTML の情報を受け取って表示するのが「静的サイト」と呼ばれるものです。「静的」なので、基本的に表示される内容は予め HTML 書かれた情報に固定されていて、別な情報を表示するにはサーバーにあるファイルを更新する必要があります。

これに対して、React や Vue は何をやっているかというと、Web ブラウザで動いているプログラムが、表示のための「HTML」をプログラムで作っているというのが、フロントエンドフレームワークの仕組みです。

Firebase などを使った場合、Firebase から「データ」だけを受け取って、表示をフレームワークで行ったりしてアプリを実現しています。この方法だと、表示の内容はデータによって帰ることもできるので「動的」に表示を変える事が可能です。

これに対して、Next や Nuxt では、表示するページの HTML をサーバーで作って Web ブラウザに送るようにしたものです。「静的」なサイト（ページ）では、予め表示するページの HTML が用意されているのに対して、「動的」なサイトの場合は、リクエストされてから表示するページを作るのが大きな違いです。

このページを Web ブラウザ側で作るのが、React や Vue がやっていることで、Next や Nuxt ではこれをサーバー側で行っています。

何故サーバー側でやるのか？

SEO に有利と言われていたのが一つの理由です。動的なサイトの場合、表示情報は Web ブラウザが Javascript を使って作っているので、ブラウザーでページのソースコードを見るとわかりますが、実際に表示されている情報をソースコード上で見ることができません。

実際は、Google などの検索エンジンはそうしたサイトにも対応しているので現在では殆ど差はないと言われています。ただし、ページの作り方によっては影響が出る場合もあります。

別の理由は、サーバーサイドでレンダリング（描画）した方が、画面の表示が速くなる場合が多いというのが理由です。これは、Web ブラウザでレンダリング（描画）する情報を作る場合、必要な Javascript をサーバーからダウンロードするまで表示ができません。サーバー側で行うと、ダウンロードされた情報から表示する事が可能になるので利用者の見た目は速く感じる場合が多いからです。

一番の利点は、セキュリティが高いという事です。Web ブラウザで動作する Javascript のソースコードは全て、Web ブラウザで見る事ができます。一方でサーバーサイドでレンダリングする場合は、表示している HTML の内容以外は見る事ができません。

サーバー側でレンダリング（描画）した方が、良いように聞こえますが欠点もあります。当たり前ですが、サーバーで処理するため、サーバーの負荷が大きくなります。また、開発も、フロントエンドだけでレンダリング（描画）するより複雑になります。

欠点も多いので、実際にサーバー側でレンダリング（描画）が必要かどうかをよく検討した上で考える必要があります。

サーバー側でレンダリングするのに必要な事は？

Web ブラウザ側でレンダリング（描画）する場合は、サーバー側で必要な機能は「Web サーバー」の機能だけです。指定された URL に必要なデータを Web ブラウザに送る仕組みがあれば対応できます。データは、HTML のファイルや、ページに埋め込まれた動画や画像ファイル、Javascript のファイル、CSS のファイルなどです。

こうした、必要なファイルを Web サーバーの決まった場所にコピーすれば Web サイトを機能させる事ができます。

サーバー側でレンダリングするには、サーバー側でレンダリング（描画）する URL が指定された時に、必要な HTML を作るプログラムを動かして、ページ情報を作る必要があります。通常は、このプログラムは動いていないので、リクエストがある度に起動する必要があります。この、ページを作るバックエンドのサービスをホスティングするサーバーで動かす必要があります。

Web ブラウザでレンダリング（描画）する場合と、サーバー側でレンダリング（描画）する場合の違いは：

＊　Web ブラウザ側：必要なファイルを渡すだけ

＊　サーバー側: 必要なファイルを渡す　＋　必要なページを作るプログラムを動かす

「必要なページを作るプログラムを動かす」という一つ余分な仕事をサーバー側で行う必要が増える事になります。

何が面倒か？

何が面倒かというと、「必要なページを作るプログラムを動かす」という事が面倒です。Nuxt の場合、Node.js のプログラムをサーバーで動かす必要があります。必要なファイル自体は、Nuxt のフレームワークが作ってくれるので問題ありません。

ところが、この Node.js のファイルを実行できないホスティングサービス多いのです！Web サイトの制作で多く利用されている WordPress の関係上、バックエンドで PHP を動かす事ができるホスティングサービスは数が多いのですが、Node.js のプログラムを動かせるサービスはそれに比べると少ないのが一つの課題です。また、Node.js が動かせるホスティングは利用に必要な料金もやや高めというのが現状です。

そうした中で、Firebase は無料から利用できる便利なサービスの一つです。

Firebase では、

＊　必要なファイルを渡す仕事　＝＞　ホスティング機能

＊　必要なページを作るプログラム => ファンクション（Cloud Function）

の２つの機能を使うと、Next や Nuxt のサーバー側でレンダリング（描画）を行うアプリもホスティングする事ができます。

まとめ

Next や Nuxt のように、サーバー側でレンダリング（描画）するアプリを作った場合、アプリをホスティングできるサーバーは限られてしまうのが現状です。 その中で、Firebase は、ホスティングとファンクションを組み合わせると、サーバー側でレンダリング（描画）するアプリでもホスティングできます。

実際のデプロイメント（インターネットへの公開）の詳しいやり方は少し複雑になるので別の記事で紹介する予定です。