Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Realtime database、Clean Architectureを組み合わせた導入事例

474 views

Published on

Firebase Realtime Database and Clean architecture.

Published in: Software
  • Login to see the comments

Realtime database、Clean Architectureを組み合わせた導入事例

  1. 1. Realtime Database、Clean Architecture、 を組み合わせた導入事例 フェンリル×モンスター・ラボ×チームラボ勉強会 2017/8/28 Monstar Lab, Inc. 菊池 達也(Tatsuya Kikuchi)
  2. 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. 3. ■具体例 ・iOSのみのネイティブアプリ開発を依頼したい。 ・短い工数で。 ・アプリに表示するコンテンツを追加したり変更したい。 ・ユーザーのログイン、ログアウトをしたい。 ・サーバー維持費とかサーバーアサインすると予算増えるからサーバーサイド 不要でどうにかならないか →仕様のスコープ調整でカバーをする。 →FirebaseのRealtime Database, Auth, Storageを利用して対応 できそう。 案件依頼内容
  4. 4. ところで、FirebaseのRealtime Databaseってなに?
  5. 5. Firebase Realtime Databaseとは ■ざっくりと概要 ・Googleで用意しているFirebaseの機能のうちのNoSQLのクラウドでホスティングす るデータベースのこと。 ・データはJSON形式でインポート、エクスポートはできるが厳密にはJSONではない。 ・モバイル向けのアプリではSDKを導入することでクラウド上のDBとアクセス可能に。 ・特徴はデータ更新時にリアルタイムにイベント通知を行える。 (チャットみたいな仕組みも実装可能に。) ■引用元 https://firebase.google.com/docs/database/?hl=ja
  6. 6. 構成 ■Firebase ・Realtime Database ・Storage ・Authentication ■Application Architectureに関して ・Clean Architectureを利用する。 ・1VC = 1Storyboard構成 ■Library ・RxSwiftを利用する。 →ユーザーやコンテンツのテーブル管理 →画像や動画ファイルなどのコンテンツ格納先 →ユーザー管理をこの機能で管理できる。Userのuniqueのidを発行など →当初は長期的なプロジェクトになりそうだったので1つ1つの 役割分担を明確化したアーキテクチャにしてメンバーがのちに ジョインしても属人化せず迷わない作りにしたいと思い採用した。 →Storyboard Referenceを活用して疎結合にし工数を抑えるのを狙いで採用した。
  7. 7. ところで、Clean Architecture とは?
  8. 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. 9. 構成 Presenter View UseCase Translator Model Repository DataStore Entity ■引用元 http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc Architectureの構成は基本は以下の通り。 Presentation Layer Domain Layer Data Layer
  10. 10. 今回採用した構成 Presenter View UseCase Translator Model ApiClient Entity ただ、そのまま使うと工数も増えるのと管理がしづらいので案件に合わせて以下のArchitectureに構成をカスタマイズした。 モバイルDBを使用しないという仕様が確定していれば状況によってはUseCaseを削除してもそのままApiClientを実行する作りに しても良いかと思う。 (実装工数が増えるため) Presentation Layer Domain Layer Data Layer Common Common Layer
  11. 11. 今回採用した構成 Presenter View UseCase Translator Model ApiClient Entity ただ、そのまま使うと工数も増えるのと管理がしづらいので案件に合わせて以下のArchitectureに構成をカスタマイズした。 モバイルDBを使用しないという仕様が確定していれば状況によってはUseCaseを削除してもそのままApiClientを実行する作りに しても良いかと思う。 (実装工数が増えるため) Presentation Layer Domain Layer Data Layer Common Common Layer Realtime Databaseでイベント更新を監視
  12. 12. 実際案件で採用してみてどうだったか。 ■Firebase □良かったところ ・そんなに複雑な処理をいらないアプリであればサーバーサイドの細かいことを知らなくても一人で作りきることができる。 ・RealtimeDatabaseの実装が簡単。 ・DBの更新イベントをアプリ内で受け取れるのでリアルタイムに画面を更新することができる。(API叩き直すとかはしなくて良 い) □つらかったところ ・NoSQLの設計ノウハウがなかったので最初はNodeの階層を深くまでつくってしまったために、必要となるデータを取り出し づらかった。 ex) imgを取り出すのにこういうことが起きる。手間がかかるので浅くDBの設計を作ると良いかと。 NodeA→NodeB→NodeC→img ■Clean Architecture □良かったところ ・仕様変更には対応しやすい。EntityとModelが分かれているので実際に値を使うときはTranslatorに救われたことは何回か あった。 □つらかったところ ・仕様変更は対応しやすいがクラスを多く作成するので仕様変更対応のインパクトが大きい。今回の案件では実装工数は増えた がRxSwiftなどライブラリを利用すること工数を減らしトータル的に工数は抑えられたかと思う。
  13. 13. サンプル ■環境 Xcode : 8.3以降 iOS :10以降 ■GitHub https://github.com/tatsuyak9/CleanArchitectureRDBSample
  14. 14. ご清聴ありがとうございました。

×