【イベントレポート】App Client Melting Pot #1「設計」に参加してきました

2019/1/10(木) に開催された、モバイルアプリ開発におけるプラットフォームを横断した技術的知見の共有を目指す勉強会、App Client Melting Pot #1「設計」に参加してきました。

 App Client Melting Pot #1「設計」

ウエルカムトーク

はじめに主催・スポンサーである株式会社FiNC Technologies様の @qsona さんより、自社のサービスや開発についての取り組みなどについてご紹介がありました。

「Fusion」という言葉をスローガンに、iOS/Android、クライアントサイド/サーバーサイドの仕様・設計・実装を一緒に考えていく取り組みをされているそうです。

この勉強会も「iOS/Androidを一緒にして同じテーマについて考える会があまりない」ということで開催されたとのことでした。

発表１

最初の発表は、PEAKSにて『iOSアプリ設計パターン入門』を執筆（共著）された、@takasek さんによる「FiNCのクライアントアーキテクチャを揃える試み」でした。

・iOS / Androidの２つの端末を並べて同時に使うわけではないので、完全に体験を合わせる必要はないが、両端末で実現したいことは変わらないことが多く、挙動が変わることは避けたい

・Kotlin/Swiftには、null安全、代数的データ型、Reactive Extensionといった両プラットフォームで使える技術がある。

・iOSはHuman Interface Guideline、AndroidはMaterial DesignとUIに関する原則は異なるが、Viewを取り除いて考えると、両プラットフォームの設計を揃えることができる。

・そのために、Presenter Domain Separation（プレゼンテーション(View)とそれ以外を分離して設計する）という考えが大切

・システム全体をGUI Architecture と System Architecture の２種類のアーキテクチャの視点で考える

といった内容が心に残りました。

発表２

続いて、Androidエンジニアで、Server Side KotlinでBFFの開発を進めていらっしゃる @izmeal2000 さんから「実践、BFF ~ BFFはFiNCのアプリで何を解決したのか~」という発表がありました。

・「通信パフォーマンス」「集約ロジックの分散」「些細な挙動変更にも申請が必要」という３つの課題を解決するためにBFF(Backends for Frontends)を採用した

・特に「集約ロジックの分散」という課題に対して、BFFを挟むことで、多数のマイクロサービスからの情報をBFFを集約させることができた

・クライアント画面で必要な情報ごとに、適切な粒度でのAPIを作ることが大切

・BFFにロジックを書くことで、iOS/Androidクライアントで重複したロジックを書かなくてすむようになった

・とはいえ、ロジックを常にBFFにロジックを寄せた方がいいということではない、ケースバイケース。

・通常BFFはUIチームによって開発されるものである by SamNewman

といった内容の話がありました。

発表３

続いて、iOSエンジニアで『iOSアプリ設計パターン入門』の著者（共著）でもある、@ktanaka117 さんによる「2つの同期、４つの状態（ステート）」というテーマでの発表でした。

・GUI Architectureを理解するため、データの同期方法と、その状態の置き方・分け方に着目した

・２つの同期方法とは、「オブザーバ同期」と「フロー同期」

・４つの状態とは「Screen State（Viewの状態）」「Presentation State（Presenterの状態）」「Session State（Modelの状態）」「Record State（DataStoreの状態）」 by Martin Fowler

・オブザーバ同期は「疎結合に同期できる」が「どこから同期イベントが送信されるかが読みずらい」

・フロー同期は「データフローが追いやすい」が「遠い場所にあるコンポーネント間の同期がしずらい」

・２つの同期方法のメリット・デメリットを理解した上で、導入する必要がある

・GUI層以下のレイヤーを増やすと「責務の分割はしやすくなるが、状態の同期にはコストがかかる」といったことが見えてくる

といったお話でした。４つの状態（ステート）という点に着目した点は非常に興味深かったです。

発表４

最後の発表は、飛び入りLTでご参加された しんくうさん による「設計の話をする前にすり合わせしたい言葉」でした。

・設計について議論する前に、そもそもその中で使われる用語についてすり合わせができているか

・「ドメイン」「モデル」「エンティティ」など用語について共通の認識ができているか、認識がずれたまま設計の議論が進んでいないか

・それぞれの設計、アーキテクチャーのメリット・デメリットについて共通の認識ができているか

といったお話でした。「過去にレイアードアーキテクチャーを導入した際に、共通の理解ができていないまま開発が進んでしまい、形だけで何のメリットもない実装になってしまった」など、具体的な事例も含めてご紹介されていました。

パネルディスカッション

発表が終わった後、発表者の @takasek さん、@ktanaka117 さん 、 @digitaljunky さんによるパネルディスカッションが、急遽開催されました。

[ Question ]  ロジックをクライアントに置くか、サーバに置くべきか、 例えば、表示用のテキストをサーバサイドで組み立てるか、クライアントサイドで組み立てるべきか

[ Answer ] クライアント側で「ボタンの長さに応じてテキストを出し分ける」といったことがあるのであれば、 クライアント側に持つ方がいいのでないか。基本UIに関わることであれば、クライアントでやる。 「UIに関わるのか」「SOLID原則に沿って検討するとどうか」 「クライアント(サーバサイド)に持つことでどんなメリットがあるのか」「今後の変更可能性はあるのか」など、 さまざま視点からの考えがあり、一概にこうとはいえない。 テキスト表示をどちらに持つかだけでも難しい問題であり、ケースバイケース、永遠のテーマ。

といったお話が展開されました。設計に正解はないというが本当にそうか？、事業が一番前に進む設計が正しい設計、ただし設計する時点ではビジネスの結果は分からないので、後から正解がわかるものではないかという言葉が、特に印象に残りました。

まとめ

会の趣旨の通り、iOS/Android、クライアントサイド/サーバサイドの共通で考えるべき問題について、非常に参考になるお話をお聞きすることができました。

第１回である今回は「設計」がテーマでしたが、第２回はどういったテーマで開催されるのか楽しみです。