serverlessconf TokyoでFirebaseの話をしてきました
11/2(木)、3(金・祝)に開催されたserverlessconf Tokyoにスピーカーとして参加してきました。
経緯
最近Realtime Databaseを扱っていて、それなりに使い方と辛みがわかってきたときに、たまたまserverlessconfのことを知って、「Firebaseもserverlessだよな」と思って、CfPを書いて出してみました。CfPに関してはリジェクトの回数の方が多いし、ましてserverlessconfでネイティブの話なんて聞きたい方いらっしゃるんだろうか、という気持ちでした。
通った
連絡がないので落ちただろうと、個人スポンサーに申し込みをして数日たった9月の最後の日のことでした。
主催の吉田さんから採択のメールが！その場ですぐプロフィールを書いて、写真をお送りしました。
10/3(火) Cloud Firestore Beta Release
夢の中で、プレゼンの構成を考え始めていたある日の朝のことです。
なんかでた。
・Documents and collections with powerful querying
・iOS, Android, and Web SDKs with offline data access
・Real-time data synchronization
・Automatic, multi-region data replication with strong consistency
・Node, Python, Go, and Java server SDKs
(あぁ…Firebaseの新しいDBだ… )
CfPが通ってからわずか数日。その日からキャッチアップが始まります。
でもこれはすごい。Realtime Databaseで辛かったところが緩和されている。
ここで、Firebase Dev Summitが開催されることを思い出します。
あぁこれは行くしかないなと思いました。Firebaseには知り合いがいて、彼にも行くのか聞いてみました。
「行くよ。子供の頃に行ったきりで覚えてないけど、Amsterdamは美しいところだと聞いているよ」
これを聞いて、Amsterdam行きの飛行機を取ったのです。
Firebase Dev Summit 2017
聞いていた通り、Amsterdamは美しいところでした。詳細は別に書きました。(Firebaseの方々にも見てもらいたかったので、英語で書いてあります）
帰ってきてからのSpeaker Dinner
11/2(木)に成田に帰ってきて、その日の夜にSpeaker Dinnerに参加しました。普段AWSやGCP, Azureなんかを触っているような方々と話すのは新鮮で面白かったです。
モバイルのSDKの話をしてみたら、問題意識もってくださってて。きっと近々よくなります。
オランダから帰ってきたばかりなので、海外から来られた方々と英語で会話するのも全く抵抗ありませんでした。
主催の吉田さんとも対面して、採択理由を軽く教えていただいたりして。臆せずにCfP出してよかった。
サーバーレス
当日会場につくとスポンサーはAWSやMicrosoftなど、iOSエンジニア募集なんて文字はどこにもありません。孤独な気持ちでいたら、iOSの仲間が駆けつけてくれていたりでなんともありがたい。
登壇は17:40でだいぶ後半戦。それまでは他の登壇者のお話を聞いたり、資料のブラッシュアップをしていました。
登壇
資料です。(ここでやっとでてきた)
話の主旨は、iOSのアプリの実装時にFirebase Realtime Databaseそのまま入れると辛いことあるから、後発のDBに置き換えやすいように設計考えようぜ！です。
話の中では、DBにアクセスするクラスが置き換えやすいこと、DBのデータ構造(Entity)と、Viewで使用するデータ(Model)が切り離されていることを再考するアーキテクチャの要件として、Clean Architectureを採用しています。
※iOSにおけるClean Architectureはよく下記の記事が参照されると思いますが、ターゲットがiOSに限定されていないため、用語に関しては、Robert C. Martinの ”Clean Architecture” を参照しています。
切り離すためには、InteractorでDBから取得したデータをJOINする必要があります。
NoSQLの原則の一つに、構造は非正規化することがあり、実際、Realtime Databaseでは、ネストは32階層までと制限もあります。
通常我々が利用するAPIは、一度リクエストを送れば、階層化されたレスポンスが返ってきますが、APIから置き換える場合には、取得したデータに含まれる別のパスへのキーを用いて、再度データの取得を行う必要があります。
つまり、これまでサーバー側で持っていたロジックをクライアント側で行う必要があるのです。
※そこでCloud Functionと併用しよう、という話の流れもありますが、今回はあくまでAPIを Realtime Databaseに置き換えたらどうなるかという話をしています。代替案として、Cloud Functionとの併用は僕もOKだと思っています。また、時間の都合上、Firestoreに時間を割くためにカットしています。
Firestoreに関してはまだβ版ということもあり、機能を大々的に宣伝するよりは、今回採用した構造が、Firestoreへのリプレイスにも強いよ、ということを示すのに使用しました。
例えば、FirestoreにはCollection型やReference型が導入されているため、どうしてもEntityやData Access Object, Interactorの構造は変わります。ですが、Interactorでのデータの変換により、ModelからViewまでは、変更する必要がありません。これでDBの変更による影響範囲が定まり、余計なデグレを引き起こしにくくなる、と個人的には思っています。
会場の反応
最近、登壇時には来られた方々の属性を把握するために、挙手していただくように努めています。ネイティブアプリのエンジニアの割合を把握したくて手をあげていただいたところ、なんと半分近くいらっしゃってました。会場も思っていたよりも多くの方々にきていただきありがたい気持ちでいっぱいです。
内容が刺さらなくて、感想も表に出て来ないのかもしれないと危惧していたら、素敵な感想をいくつかいただきました。
swiftからFirebase Realtime Databaseで色々とハマったクチだったので、セッションは大頷きしながら聞いてました。
こちらももう一度スライドを反芻したいです！
こういった感想をいただくと、本当に登壇してよかったと報われた気持ちになります。
まとめ
普段関わりのないコミュニティのカンファレンスに登壇したのは初めてでしたが、臆せずCfPを出してみたら、楽しかったです。これを気に、serverlessのことももっと知ろうと思いました。ぜひ知的な便秘にならないようにアウトプットしていきましょう！
