Web上で簡単にきれいなトーナメント表が作れる、「THE TOURNAMENT」という超絶地味なサービスを運営しています。
最初に作ったのが2014年だったので、気づけばもう運営4年目。
ずっと「Rails×Heroku」で運用してきたのですが、ちょうど先日サービスを全面リニューアルして、「Riot.js×Firebase」に移行しました。
そんなお引っ越しの記録と振り返ってみての感想です。
🤔なんで移行したの？
大前提として、HerokuとRailsは今でも大好きですw
じゃあなんで移行したんだよって話ですが、理由は大きく以下の２つでした。
- Herokuを無料で使い続ける限界が近づいていた
- トーナメント作成をjsベースでインタラクティブにしたかった
前にこんなLTもしましたが、トーナメントは相当アクセスが増えても無料でしのげる仕組みにはしていました。
とはいえおかげさまで作成側の負荷も増えてきていたのと、DBも無料だと1万レコード制限があって、そろそろこれも限界が近づいていました。
また、リニューアルの大きな目的の1つが、jsでインタラクティブにトーナメント表を編集できるようにすることでした。
Webpackerでjsフレームワークの導入に挑戦するという選択肢もあったのですが、まぁ率直に「これRailsじゃなくてよくね？」と気づいてしまったのは否定できません。
というか、こういうフロント中心のサービスでバックエンドも楽したいって思ったときに、Firebaseがどんぴしゃすぎるんですよね。。 別のプロダクトで1年くらいFirebaseを運用していたこともあり、もうこれでいいんじゃないのーと思えたのも移行のきっかけです。
1年前の時点でフロントエンドのフレームワークはまったく経験がなかったので、一番シンプルで学習コストが低そうなRiot.jsをチョイスしてました。いまならVue.jsにしてたかもですが、Riot.jsもこれくらいの規模なら全然問題なく、シンプルでよい感じです。
😇 移行してみてのうれしみ
無料枠が大きすぎ
FirestoreもHostingもFunctionsも、いまのところ無料枠で収まりそうです。うれしい。
しかもつい先日、従量課金型のBlazeプランにも無料のSparkプランとほぼ同じ無料枠が割り当てられるようになりました。 （いままではBlazeを選択したら最初の1バイトから課金対象になってた）
これなら基本無料で運用できて、急なアクセス増のときだけ従量課金でさばいてくれるので、かなりよさそうです。
ただBlazeは上限設定ができないのが怖くてまだ移行してないけど。。
ユーザー認証が簡単すぎ
FirebaseのAuthenticationは、めちゃくちゃよくできています。
デフォルトで主要SNSログインの仕組みも用意してくれてるので、各SNS側でアプリだけ作って指示通り設定すれば、すぐにログインの仕組みができてしまいました。
さらに最近のアップデートでパスワード不要のメールログインの仕組みが公式に実装されました。神！
Authenticate with Firebase Using Email Link in JavaScript | Firebase
自前で同じ仕組みを実装してたので、早く乗り換えねば。
Functionsが便利すぎ
これはほんとに便利。
うちではデータの更新を検知して、なんちゃってSSRみたいなことをして静的HTMLを出力するという処理を走らせています。
いままではHerokuのSchedulerアドオンでバッチ処理を走らせて同じことをしていました。 ただこれがFree Dynoのメモリを圧迫していて、処理が安定しなくなっていた原因でもありました。
Functionsは無料プランでも結構なキャパがあるので、頼もしいです。すごい。
💩 移行してみてのつらみ
一方でFirebaseに移行して感じているつらみと不安。
カジュアルに障害が起きる
ベータのサービスが多いせいもありますが、よく落ちます。
自分が使っている範囲だと特にHostingとFunctionsがやばい。カジュアルに落ちます。
インフラ側で落ちちゃうとどうしようもなくて結構困ってしまうのですが、DB（Firestore）が無事でHostingが落ちてるだけなら、最悪Storageにでも置きなおしてドメイン振ればいけるはず。
一方でFirestoreが落ちると、けっこうどうしようもないですね。どうしよう。 今のところFirestoreはほぼ障害ないのが救いですが。。（レスポンスがめっちゃ遅くなるときはある）
管理画面が貧弱
サービスを運営していると、データをちょっと修正したいときとかあるじゃないですか。 Firebaseの公式管理画面（コンソール）だと、これがものすごく大変です。 データの一覧性もないし、検索性はほぼないし、クエリ投げたりもできないし。。
SequelPROとかPSequelみたいなやつがほしいので、とうとう自分でGUIアプリを作り始めてしまいましたw
興味ある人はプライベートβにご招待しますので、ぜひフィードバックに協力してくれるとうれしいです。 お気軽にご連絡ください。
データバックアップができない
できません。どうしたらいいんですか（切実）。
RealtimeDatabaseは有料プランならバックアップオプションが用意されてたんですが、Firestoreは有料版でもそもそも存在しない。。 一応npmモジュールでバックアップ取れるやつがあるので触ってみてますが、もうちょっと公式でサポートしてほしい。
初回表示が遅くなった
これはfirebaseの問題というより、SPA化したことの弊害ですね。 何も考えずにSPA化すると、最初の読み込みが重くなりがち。一回読み込めば中の遷移はさくさくなんですけどね。
キャッシュがない状態でもユーザービリティを損なうほど遅いわけじゃないので、いったん後回しにしてます。 ただPageSpeedInsightとか Lighthouseとかでauditしてみると、めっちゃ怒られる。。
トップページから入ってきて中に進むユーザーが多いので、将来的にはトップページを静的にしてAMP化、後続のアプリ部分をPWA化しておいて、AMPアクセス時にpreloadするような仕組み（PWAMP！）にすれば爆速化できるんじゃないかと思ってます。が、PWAこわくてまだ手を出せてない。
MobileFirstIndexも始まったし、そろそろやらねばですね。がんばる。。
SEOも弱くなった
これまたよく言われるSPA化の弊害で、見事にはまってしまいました。
- Googleにインデックスされず、SEOに弱くなった
- SNSシェア時にOGPが反映されない
どちらもbotがアクセスしてきたときに、動的に変更してるmetaタグを読めず、エンドポイントのindex.htmlに書いてあるデフォルトのmetaタグを読んじゃってることが原因です。
これについては、特にSEO/OGPが必要になるコンテンツページに絞って、Functionsで動的にmetaタグを書き換えて配信することで一応対応できました。
Cloud Functions による動的コンテンツの配信 | Firebase
またbotがページ内のリンクたどれてるかもあやしいので、sitemapとRSSフィードを配信してクロールしやすくもしています。
この辺の詳細はまた別で整理してみようかと。
（2018年4月3日追記）
書きました。
まとめ
なぜかうれしみよりつらみの方が多くなってしまった。なぜだ。。 しかし実際にリニューアルは不可避でしたし、いまのところ非常にうまく機能してると思います。
またぼくが解決策を知らないだけの可能性もあるので、もしお気づきのところあれば指摘もらえるとうれしいです。 ベータ版を抜ければ解決しそうな問題も多いので、早く公式で色々対応してくれるといいですね。
信じてもらえないかもしれないけど、Firebaseは本当におすすめですよ。 みんな早くおいで！
おしまい。