徹底比較!Firebase vs Netlify (2018年版)

みなさまこんにちは、のびーことfnobiです。今年ももうアドベントカレンダーの季節なんですね。はやいはやい。

さて個人的にアドベントカレンダーでは、振り返りの意味も込めて その年お世話になった技術に関する記事を書く、というルールにしてますので、今回は NetlifyとFirebaseの話 をします!! (ちなみにFirebaseの話は去年もしたかったのですが、時間が足りなかった&他の人も書いてたのでパスしました)

この記事の目的

いまフロントエンドエンジニアに使ってほしいサービスの私的TOP2・NetlifyとFirebaseについて、様々な観点から比較して、 「なんかどちらも便利そうって聞くけれど、どちらを使えばいいのかわかんないな??」 という人をこの世からなくします!

f:id:nobiii:20181207040856p:plain

Netlifyってなんぞや?

  • https://www.netlify.com/
  • githubと連携可能な静的Webホスティングサービスです。
  • 「静的」と言いつつ、CI機能や補助的に提供されているバックエンドの機能が恐ろしく豊富なので、もはや静的と呼んではいけない気がしてます。
  • 今年は、元社員のなべさんに誘ってもらって、Netlify入門の同人誌を共著したりしました。まだ買えるので買って。

Firebaseってなんぞや?

  • https://firebase.google.com/
  • Googleが提供している mBaaS です。(mobile Backend as a Service)
  • 一番の特徴はリアルタイムデータベースですが、他にも様々な機能が提供されています。
  • モバイルアプリのバックエンドとして利用することが主眼に置かれているサービスですが、Webフロントでも非常に便利に扱えます。
  • 今年は、アイドルとハイタッチした回数を数える のに使ったりしました。

ROUND1: Webサイト公開に使いたい!

まずは基本の機能です。NetlifyでもFirebaseでも、静的なWebサイトを非常に手軽に公開することができますが、果たしてどちらが便利なんでしょうか???

デプロイ手順

  • →Netlifyの方が簡単・便利!

まずNetlifyの方で、サイトの公開を始めるには、管理画面上からGithubレポジトリを選んで、デプロイしたいブランチ・公開ディレクトリ・ビルド時に呼び出したいコマンド名を入力するだけです。これだけで、以後指定したブランチに新しいコミットがあるたびに、Netlify側でビルドコマンドを実行→結果生成されたファイルをデプロイ、というところまで勝手にやってくれます。簡単!

f:id:nobiii:20181206185349p:plain
Netlifyをgithubと連携するときの設定

対してFirebaseは、Webホスティング機能はあくまで補助的なものなので、まずプロジェクトの管理画面に入ってHostingの機能をオン・準備ができたら、コマンドラインから以下の操作を行うことでデプロイができます。

# 手元のソースコードと、firebaseの特定のプロジェクトを紐付ける
$ firebase init
# (対話式でいろいろ聞かれるので設定を書く)

# デプロイ実行
$ firebase deploy --only hosting

f:id:nobiii:20181206185449p:plain
Firebaseのhosting機能をオン

簡単だ!という気もしますが、こちらは単発でデプロイを実行するための操作なので、当然ながら以後デプロイしたくなった際は、そのたびに手動でこちらを実行する必要がありますし、フロントのコードのビルドが必要な場合はそちらも手動で呼び出す必要があります。

Webサイトを1度しかデプロイしない、ということはそうそうないと思いますので、コミットにフックしてそのあたりを全部入りでやってくれるNetlifyの方が、この点では優秀ですね!

もちろんFirebaseのホスティングを使った場合でも、circleci等のCIサービスと併用することで、同様の自動化を行うことは可能ですので、このあたりの設定に慣れている方はFirebaseでも何ら困らないかもしれませんね。

配信速度(CDN)

  • →Firebaseの方がめっちゃ速い

静的コンテンツしかないのであれば、表示速度もめっちゃくちゃ速いはずだよな???と期待しちゃいますよね。こちらはどうなのでしょうか!

これについては、既に比較をしてくれた方がいるので記事を参照しましょう。

どうやらFirebaseの圧勝のようです。(去年の記事ですが、最近使っていての体感としてもそんなに変わってないように思います)

要因としては、Firebase側はhttp2にも対応しているだとか、レスポンスヘッダを見るとfastlyという今非常に優秀と言われているCDNを噛ませているらしいとか、そのあたりが挙げられそうです。

利用料金

  • →Netlifyは(単なるホスティングに関しては)完全無料!

もう最初の1行で話が終わっちゃってる気もしますが、コスト面では完全に無料で使えるNetlifyが優秀です。(ホスティング以外の機能を使う際に、別途課金が必要なものもあります)

ただしFirebaseの方も、ファイル保存1GBまで・転送量10GB/月までは無料プランのままで利用可能です。用途によってはこちらでも全く問題ないでしょう。

独自ドメイン・SSL

  • →引き分け(どちらもとても簡単)

どちらのサービスでも、公開するサイトに独自ドメインをあてることができます。ドメイン提供側でDNSレコードを各サービスに向けてあげればOKです。どちらのサービスもホスティング関連の設定まわりに記載があるのでそんなに迷わないと思います。

f:id:nobiii:20181206185555p:plain
Netlifyのドメイン設定

f:id:nobiii:20181206185631p:plain
Firebaseのドメイン設定

またhttps対応については簡単どころか、筆者の場合 気がついたらなってました 。(どちらの場合も)

公開前のサイトにパスワードをかけたい

  • →引き分け

こちらは難しいところです。順番に見ていきましょう。

まずNetlifyには、Access Controlという機能が搭載されており、こちらからサイト自体にパスワードロックをかけることができます。管理画面からのみの操作で、非常に簡単です。

f:id:nobiii:20181206185712p:plain
こんな感じでパスワードロックがかけられる

ただしこちらは 有料プランの機能 です。Netlifyの課金プランは、teamごとの課金になり、この機能の場合は$45/月の「Team Pro」以上が必要です。

対するFirebaseは、サービス側ではこのような機能を提供していません。ただし、後述のcloud funtionsと、簡単な実装でbasic認証を動かすことは可能です。実装さえすれば無料プランでも実現可能ですので、Expressの実装に抵抗がない方はこちらを検討してみてください。

ROUND2: サーバーの機能を楽に使いたい

この両サービスは、Webホスティングができるだけでも非常に便利なのですが、加えて便利なサーバーサイド機能も、コーディング無しでゴリゴリ利用できるのが素晴らしいところです。 正直これらのサービスの出現で、いままでなら「静的サイトではできません!」と言っていたことが嘘になる・実装のフィジビリティ自体が変わってくるくらいの変化が起きていると思うので、 これからのフロントエンドエンジニアは把握しておかないと不誠実 です。要チェック!

データベース・ファイルストレージ

  • →圧倒的にFirebase

これはまあ、比べるまでもなくFirebaseが強いです。(というか本来はこちらを提供しているサービスですね)

jsのSDKを組み込むだけで、簡単にリアルタイム通信・json storeが実現できるFirebase Realtime Database、それをさらに進化させて複雑なデータ検索にも対応できるFirestore、フロントで生成・アップロードしたファイルを簡単に保存できるFirebase Storage、それぞれ無料で使い始めることが可能ながら、とても可能性を秘めたサービスです。

特に、サーバーサイドは苦手というフロントエンドエンジニアの方は、できることが大きく広がりますのでぜひ一度お試しを。ただし、フロントから全てを制御するという関係上、データ構造の組み方や権限設定の付け方には少々癖がありますのでご注意を。

Netlifyには、データベースやファイルストレージを提供する仕組みは現状ありません。無念。

代替と言えるかは怪しいですが、Netlifyでホスティングしているサイトから、紐づけたGithubに任意のファイルをコミットできるAPIインタフェースを生やすGit Gatewayという凄まじい機能があったりするので、うまいことやれば使えるかもしれません。

ちなみにnetlify-cmsというサードパーティーのサービスは、このGit Gatewayをうまく使って、NetlifyだけでCMSを実現しています。(このあたりは序盤で触れたNetlifyの同人誌に詳しく書いたので読んでみてね)

認証

  • →Firebaseが非常によしなで便利

ユーザー認証して、特定の人にしか見えないサイトをつくる、という要件もFirebaseを使えばサーバーサイド実装なしで実現可能です!特にgoogleアカウントでのログイン機能は、googleが提供しているサービスだけあって非常に簡単につくれます。

また認証自体の実装が簡単なだけでなく、先述のRealtime Database上で特定ユーザーだけにread/write権限を付ける、ということもできるので、アプリケーションの挙動に認証を組み込むことも容易です。

Netlifyも、Identityという機能でユーザー管理・認証を提供しています。メールアドレスとパスワードでの認証であれば、招待メールの送信・ログイン時のUIの提供など必要になりそうなものは一通り揃っている状態です。とはいえ、メールアドレスでの認証に限られること・フロントからユーザー情報をとろうとすると別ライブラリも用いた実装が必要だったりと、使い勝手としてはFirebaseの方がよいと言えそうです。

フォーム

  • →Netlifyに標準搭載されているformがすごい

コーポレートサイトなどで、サイトの大部分は静的なのだけれど、問い合わせフォームだけは動的に作らなくてはいけない!というようなケースはよくあるのではないでしょうか。 Netlifyではこのようなケースに向けてなのか、formタグを埋め込むだけで呼び出せるForms機能が搭載されています。なんともかゆいところに手が届きますね。

f:id:nobiii:20181207034415p:plain
これだけのHTMLを埋め込むだけで、フォームのバックエンドが勝手に作られる

Firebaseにこのような機能はありません。functionsを用いて、同等の処理を自分で実装をすることは可能です。

functions

  • →互角

サーバー上で動作するjavascriptコードを適宜追加できるfunctions機能は両サービスが提供しています。上で紹介したようなサーバーサイドの機能では目的にそぐわない場合でも、自前で実装すればなんとかなる場合もあるので、積極的に利用していきましょう。

Firebaseの場合、先述のデータベース・ファイルストレージ機能とも簡単に連携できるようになっており、いろいろと使い勝手はよいと言えます。なお無料プランでは、 外部ネットワークと通信する処理は制限されている という点に注意です。

対してNetlifyのfunctionsは完全無料です。なお、こちらの中身は完全にAWS lambdaでできているようなので、デプロイ等の設定がNetlify向けに調整されたAWS lambdaのラッパー、という見方もできますね。

ROUND3: そのほか

料金形態

実際にサービスを選択する際に注意したいのは、それぞれのサービスの料金形態です。

Firebaseは 「基本的なことは無料でもできるけれど、本格的に運用する場合はプロジェクトごとに有料プラン契約してね」 というスタイルです。ホスティングやデータベースの転送量が多い場合・functionsで外部ネットワークとの通信も使いたい場合などに有料プランが必須になります。

$25/月で固定のFlameプラン・従量課金のBlazeプランが用意されています。とはいえBlazeプランの場合でも、無料枠が設けられているなど料金はかなり良心的なので、サーバー費がネックになるということはあまりない印象です。

Netlifyの方が、ここまででも触れているように、無料プランのままできることが多いサービスと言えます。ホスティング・CIといった基本機能についてはどれだけ使っても無料です。ひとつのNetlifyプロジェクトを複数人で管理したいとき・アクセス制限やユーザー管理等の高度な機能を使いたくなったときに、課金が必要です。

なおNetlifyの有料版機能は プロジェクト単位でON/OFFできず、ユーザー側・組織側のプランに紐付いている というのが気をつけたいポイントです。例えば、10人のエンジニアでNetlifyを扱いたい場合、運用しているプロジェクトが一つだったとしても、$290/月のTeam Businessプランを契約する必要があります。個人での開発で使ってみる分にはあまり気になりませんが、会社で導入を検討している方は覚えておきましょう。

まとめ

いかがでしたか?どちらのサービスにもそれぞれの得意分野があることが分かっていただけたら幸いです。

個人的には、 データベース・ファイルストレージが使いたい場合はすべてFirebaseに乗せる・それ以外の場合はすべてNetlifyに乗せる くらいのイメージです。functionsのおかげでまあ、自前実装も選択肢に入れればだいたいのことはできるので、決め手になる機能の使いやすさで決めてしまってもよいでしょう。

明日は id:s_gozaru の記事です。なにやら珍しい話を仕入れているようなので楽しみにしていてください!