NOT SO BADなブログ

ぼっちスタートアップが日々がんばっています

3年間運用してきたWebサービスを「Rails x Heroku」から「Riot.js x Firebase」に移行した話

f:id:o_tomomichi:20180312145525p:plain

Web上で簡単にきれいなトーナメント表が作れる、「THE TOURNAMENT」という超絶地味なサービスを運営しています。

the-tournament.jp

最初に作ったのが2014年だったので、気づけばもう運営4年目。

ずっと「Rails×Heroku」で運用してきたのですが、ちょうど先日サービスを全面リニューアルして、「Riot.js×Firebase」に移行しました。

そんなお引っ越しの記録と振り返ってみての感想です。

(2018年8月追記)

Firebaseは恐ろしい勢いで改善し続けているので、この記事に書いてあるつらみもどんどん解消されつつあります。 ますますおすすめなのでぜひ使ってみてください。

The Firebase Blog: More Cloud Firestore Improvements!

(追記おわり)


🤔なんで移行したの?

大前提として、HerokuとRailsは今でも大好きですw

じゃあなんで移行したんだよって話ですが、理由は大きく以下の2つでした。

  • Herokuを無料で使い続ける限界が近づいていた
  • トーナメント作成をjsベースでインタラクティブにしたかった

前にこんなLTもしましたが、トーナメントは相当アクセスが増えても無料でしのげる仕組みにはしていました。

blog.notsobad.jp

とはいえおかげさまで作成側の負荷も増えてきていたのと、DBも無料だと1万レコード制限があって、そろそろこれも限界が近づいていました。

また、リニューアルの大きな目的の1つが、jsでインタラクティブにトーナメント表を編集できるようにすることでした。

f:id:o_tomomichi:20180331115841p:plain

Webpackerでjsフレームワークの導入に挑戦するという選択肢もあったのですが、まぁ率直に「これRailsじゃなくてよくね?」と気づいてしまったのは否定できません。

というか、こういうフロント中心のサービスでバックエンドも楽したいって思ったときに、Firebaseがどんぴしゃすぎるんですよね。。 別のプロダクトで1年くらいFirebaseを運用していたこともあり、もうこれでいいんじゃないのーと思えたのも移行のきっかけです。

1年前の時点でフロントエンドのフレームワークはまったく経験がなかったので、一番シンプルで学習コストが低そうなRiot.jsをチョイスしてました。いまならVue.jsにしてたかもですが、Riot.jsもこれくらいの規模なら全然問題なく、シンプルでよい感じです。


😇 移行してみてのうれしみ

無料枠が大きすぎ

FirestoreもHostingもFunctionsも、いまのところ無料枠で収まりそうです。うれしい。

しかもつい先日、従量課金型のBlazeプランにも無料のSparkプランとほぼ同じ無料枠が割り当てられるようになりました。 (いままではBlazeを選択したら最初の1バイトから課金対象になってた)

firebase.googleblog.com

これなら基本無料で運用できて、急なアクセス増のときだけ従量課金でさばいてくれるので、かなりよさそうです。

ただBlazeは上限設定ができないのが怖くてまだ移行してないけど。。

ユーザー認証が簡単すぎ

FirebaseのAuthenticationは、めちゃくちゃよくできています。

デフォルトで主要SNSログインの仕組みも用意してくれてるので、各SNS側でアプリだけ作って指示通り設定すれば、すぐにログインの仕組みができてしまいました。

f:id:o_tomomichi:20180312141940p:plain

さらに最近のアップデートでパスワード不要のメールログインの仕組みが公式に実装されました。神!

Authenticate with Firebase Using Email Link in JavaScript  |  Firebase

自前で同じ仕組みを実装してたので、早く乗り換えねば。

Functionsが便利すぎ

これはほんとに便利。

うちではデータの更新を検知して、なんちゃってSSRみたいなことをして静的HTMLを出力するという処理を走らせています。

f:id:o_tomomichi:20180312142426p:plain

いままではHerokuのSchedulerアドオンでバッチ処理を走らせて同じことをしていました。 ただこれがFree Dynoのメモリを圧迫していて、処理が安定しなくなっていた原因でもありました。

Functionsは無料プランでも結構なキャパがあるので、頼もしいです。すごい。


💩 移行してみてのつらみ

一方でFirebaseに移行して感じているつらみと不安。

カジュアルに障害が起きる

ベータのサービスが多いせいもありますが、よく落ちます。

自分が使っている範囲だと特にHostingとFunctionsがやばい。カジュアルに落ちます。

インフラ側で落ちちゃうとどうしようもなくて結構困ってしまうのですが、DB(Firestore)が無事でHostingが落ちてるだけなら、最悪Storageにでも置きなおしてドメイン振ればいけるはず。

一方でFirestoreが落ちると、けっこうどうしようもないですね。どうしよう。 今のところFirestoreはほぼ障害ないのが救いですが。。(レスポンスがめっちゃ遅くなるときはある)

管理画面が貧弱

サービスを運営していると、データをちょっと修正したいときとかあるじゃないですか。 Firebaseの公式管理画面(コンソール)だと、これがものすごく大変です。 データの一覧性もないし、検索性はほぼないし、クエリ投げたりもできないし。。

データバックアップができない

できません。どうしたらいいんですか(切実)。

RealtimeDatabaseは有料プランならバックアップオプションが用意されてたんですが、Firestoreは有料版でもそもそも存在しない。。 一応npmモジュールでバックアップ取れるやつがあるので触ってみてますが、もうちょっと公式でサポートしてほしい。

初回表示が遅くなった

これはfirebaseの問題ではなく、SPA化したことの弊害ですね。 何も考えずにSPA化すると、最初の読み込みが重くなりがち。一回読み込めば中の遷移はさくさくなんですけどね。

キャッシュがない状態でもユーザービリティを損なうほど遅いわけじゃないので、いったん後回しにしてます。 ただPageSpeedInsightとか Lighthouseとかでauditしてみると、めっちゃ怒られる。。

トップページから入ってきて中に進むユーザーが多いので、将来的にはトップページを静的にしてAMP化、後続のアプリ部分をPWA化しておいて、AMPアクセス時にpreloadするような仕組み(PWAMP!)にすれば爆速化できるんじゃないかと思ってます。が、PWAこわくてまだ手を出せてない。

www.ampproject.org

MobileFirstIndexも始まったし、そろそろやらねばですね。がんばる。。

SEOも弱くなった

これもFirebaseは関係なく、よく言われるSPA化の弊害に見事にはまってしまいました。

  • Googleにインデックスされず、SEOに弱くなった
  • SNSシェア時にOGPが反映されない

どちらもbotがアクセスしてきたときに、動的に変更してるmetaタグを読めず、エンドポイントのindex.htmlに書いてあるデフォルトのmetaタグを読んじゃってることが原因です。

これについては、特にSEO/OGPが必要になるコンテンツページに絞って、Functionsで動的にmetaタグを書き換えて配信することで一応対応できました。

またbotがページ内のリンクたどれてるかもあやしいので、sitemapとRSSフィードを配信してクロールしやすくもしています。

この辺の詳細はまた別で整理してみようかと。

(2018年4月3日追記)

blog.notsobad.jp

書きました。


まとめ

なぜかうれしみよりつらみの方が多くなってしまった。なぜだ。。 しかし実際にリニューアルは不可避でしたし、いまのところ非常にうまく機能してると思います。

またぼくが解決策を知らないだけの可能性もあるので、もしお気づきのところあれば指摘もらえるとうれしいです。 ベータ版を抜ければ解決しそうな問題も多いので、早く公式で色々対応してくれるといいですね。

信じてもらえないかもしれないけど、Firebaseは本当におすすめですよ。 みんな早くおいで!

おしまい。