Diary

Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。

用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。

Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。

Cloud Functions はようするに Firebase の Lambda + API Gateway で、 Firestore になにかが保存されたことをトリガーにして「サーバーレス」のコードが起動される。

典型的にこのトリガーを使うのは以下二つの用途であろうと思う

• 全文検索
  • Firebase に全文検索が実装されていないので外部の全文検索エンジンを使う必要がある
  • 2018 年現在、 Algolia というサービスを使うように推奨されている
    • Firebase の話をあんまり関係ないがこの Algolia は出来がよく大変に便利、 Firebase を使わない人も検討の価値あり
• BigQuery
  • 集計クエリとかは BigQuery に吐いてもらう必要があるだろう、 Firestore への保存をトリガーに BigQuery にコピーするコードを書くのは簡単

そして Cloud Functions には API Gateway 的な機能が高度に統合されており、 AWS でやるよりも簡単にサーバーレスな API を作成、デプロイすることができる。

典型的にはこれは以下のような用途で使用されると思う

• 全文検索
  • Algolia で検索行なうときにアプリの設計次第では適切に権限が制限されたアクセストークンを発行する必要があるが、これをクライアントサイドで行なうことは原理的に不可能なのでサーバーサイドで行なう
• BigQuery
  • BigQuery に実際に SQL を投げて結果を返す API はサーバーサイドに作るほうが何かと楽だし、適切にクオータなどもかけられる
• 認証
  • Firebase が公式に認証フローを用意していないサービスでも Cloud Functions などを使ってサーバサイドを実装すれば Firebase へのログインに利用可能、これについては前に書いた
• 決済
  • Firestore への保存をトリガーに決済を行なう形式は危険、なぜならトリガーは「確実に一回実行されること」が保証されない。複数回走る可能性がある。

こうした API を作成するのに必要な知識は、

• node.js で普通に Web アプリを作る知識
• HTTP ヘッダーを使って認証をする現代で普通のやり方

などであって、極普通にバックエンドエンジニアの知識であろうと思う。

Firebase で本当に不要になるのは「インフラエンジニア」だが、これも実際にアプリが大きくなってくるとどうなるか分かない。すなわち

• CI/CD 環境の整備
• 各種デプロイ、データアクセスの権限の整備
• Cloud Firestore などのデータベースの運用
• Cloud Functions 経由で MySQL などを利用する場合はそれらの整備

といったタスクが出てくることは明らかで、これを解決できるのは、その人がその会社でどのように呼ばれていようと「インフラエンジニア」であろうと思う。

しかし、 Firebase を使う場合でもこうした人達が必要で、結局 Firebase を使う意味はなく、従来のとおりのアプリ開発が結局優位性を持つのか、というとそうではないと思う。

• 多くのことをバックエンドエンジニアとインフラエンジニアに頼らず出来る
  • 彼等は不要にならないが、少なくはできる
• Realtime Database によるデバイス間同期は極めて強力

といった事情で極めて強力、2018 年に 1 からアプリを作る場合最も有力な選択肢の一つだと思う。