Firebase Realtime Database and Clean architecture.

1. Realtime Database、Clean Architecture、
を組み合わせた導入事例
フェンリル×モンスター・ラボ×チームラボ勉強会
2017/8/28
Monstar Lab, Inc.
菊池 達也(Tatsuya Kikuchi)

2. 自己紹介
菊池 達也(きくち たつや)
生年月日 : 1987/10/9
日本大学 理工学部 精密機械工学科 卒業
■SNS
Facebook :菊池 達也
Github : tatsuyak9
Instagram : tatsuyak9
■経歴
受託開発の企業にてAndroid,iOS,Web向けのアプリケーション開発を行ってきました。
2015年にMonstar Lab, Inc.に入社し、入社してすぐ2年間客先に常駐していました。
そこではiOSのSDK、iOS、tvOSのアプリ開発のリードエンジニアとして携わりました。
今年2月に自社に戻り現在はiOS、Unityの受託開発の案件をメインに携わっています。

3. ■具体例
・iOSのみのネイティブアプリ開発を依頼したい。
・短い工数で。
・アプリに表示するコンテンツを追加したり変更したい。
・ユーザーのログイン、ログアウトをしたい。
・サーバー維持費とかサーバーアサインすると予算増えるからサーバーサイド
不要でどうにかならないか
→仕様のスコープ調整でカバーをする。
→FirebaseのRealtime Database, Auth, Storageを利用して対応
できそう。
案件依頼内容

4. ところで、FirebaseのRealtime
Databaseってなに？

5. Firebase Realtime Databaseとは
■ざっくりと概要
・Googleで用意しているFirebaseの機能のうちのNoSQLのクラウドでホスティングす
るデータベースのこと。
・データはJSON形式でインポート、エクスポートはできるが厳密にはJSONではない。
・モバイル向けのアプリではSDKを導入することでクラウド上のDBとアクセス可能に。
・特徴はデータ更新時にリアルタイムにイベント通知を行える。
(チャットみたいな仕組みも実装可能に。)
■引用元
https://firebase.google.com/docs/database/?hl=ja

6. 構成
■Firebase
・Realtime Database
・Storage
・Authentication
■Application Architectureに関して
・Clean Architectureを利用する。
・1VC = 1Storyboard構成
■Library
・RxSwiftを利用する。
→ユーザーやコンテンツのテーブル管理
→画像や動画ファイルなどのコンテンツ格納先
→ユーザー管理をこの機能で管理できる。Userのuniqueのidを発行など
→当初は長期的なプロジェクトになりそうだったので1つ１つの
役割分担を明確化したアーキテクチャにしてメンバーがのちに
ジョインしても属人化せず迷わない作りにしたいと思い採用した。
→Storyboard Referenceを活用して疎結合にし工数を抑えるのを狙いで採用した。

7. ところで、Clean Architecture
とは?

8. Clean Architectureとは
■ざっくりと概要
・ビジネスロジックをUIやFrameworkか
ら引き離し、それぞれの層毎に役割と責任
を分離したArchitectureである。
→このArchitectureを採用することでどの
処理がどこで行われているか分かるため実
装で迷うことは少ない。
■引用元
http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

9. 構成
Presenter
View
UseCase
Translator
Model
Repository DataStore
Entity
■引用元
http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc
Architectureの構成は基本は以下の通り。
Presentation Layer Domain Layer Data Layer

10. 今回採用した構成
Presenter
View
UseCase
Translator
Model
ApiClient
Entity
ただ、そのまま使うと工数も増えるのと管理がしづらいので案件に合わせて以下のArchitectureに構成をカスタマイズした。
モバイルDBを使用しないという仕様が確定していれば状況によってはUseCaseを削除してもそのままApiClientを実行する作りに
しても良いかと思う。
(実装工数が増えるため)
Presentation Layer Domain Layer Data Layer
Common
Common Layer

11. 今回採用した構成
Presenter
View
UseCase
Translator
Model
ApiClient
Entity
ただ、そのまま使うと工数も増えるのと管理がしづらいので案件に合わせて以下のArchitectureに構成をカスタマイズした。
モバイルDBを使用しないという仕様が確定していれば状況によってはUseCaseを削除してもそのままApiClientを実行する作りに
しても良いかと思う。
(実装工数が増えるため)
Presentation Layer Domain Layer Data Layer
Common
Common Layer
Realtime Databaseでイベント更新を監視

12. 実際案件で採用してみてどうだったか。
■Firebase
□良かったところ
・そんなに複雑な処理をいらないアプリであればサーバーサイドの細かいことを知らなくても一人で作りきることができる。
・RealtimeDatabaseの実装が簡単。
・DBの更新イベントをアプリ内で受け取れるのでリアルタイムに画面を更新することができる。(API叩き直すとかはしなくて良
い)
□つらかったところ
・NoSQLの設計ノウハウがなかったので最初はNodeの階層を深くまでつくってしまったために、必要となるデータを取り出し
づらかった。
ex) imgを取り出すのにこういうことが起きる。手間がかかるので浅くDBの設計を作ると良いかと。
NodeA→NodeB→NodeC→img
■Clean Architecture
□良かったところ
・仕様変更には対応しやすい。EntityとModelが分かれているので実際に値を使うときはTranslatorに救われたことは何回か
あった。
□つらかったところ
・仕様変更は対応しやすいがクラスを多く作成するので仕様変更対応のインパクトが大きい。今回の案件では実装工数は増えた
がRxSwiftなどライブラリを利用すること工数を減らしトータル的に工数は抑えられたかと思う。

13. サンプル
■環境
Xcode : 8.3以降
iOS :10以降
■GitHub
https://github.com/tatsuyak9/CleanArchitectureRDBSample

14. ご清聴ありがとうございました。