---

こんにちは〜

【勉強会】App Client Melting Pot #1「設計」に行ってきた

app-client-mp.connpass.com

個人でiOSアプリを作ろうとしていて、アプリの設計面とかよくわからないな〜と思っていたので行ってきた。
メモしたことや感想を書き起こし。

ウェルカムトーク by @qsona さん

  • Client Fusion
    • iosandroidの開発チームを融合する
    • iosandroidでチームを分けると、それぞれの機能で齟齬が出たりする
  • Client Server Fusion
    • 40個くらいのマイクロサービスが動いているので、
    • クライアントとサーバーのコミュニケーションを密にする必要がある
  • 機能が多く複雑で、技術的負債がたまりやすい
  • BFF(Backends for Frontends)を進めている

FiNCのクライアントアーキテクチャを揃える試み by @takasek さん

揃えて良かった点は?

  • ドメインへの意識が高まった
  • 仕様の考慮漏れ、設計の悪さに気づける
  • iosandroidが実質ペアプロ
  • コンテキストを安定させる
    • 「境界はチーム編成の輪郭に従う」

iosandroidの同時開発は非効率では?

  • それな
  • 自走できる部分は自走した方がいい
  • プロトタイプレベルは片方が先行開発
  • 片方が先行リリース→フィードバクを元に追加開発

ロジックはサーバーサイドに寄せるべきでは

一概にそうとは言えない

  • 分散コンピューティングの原則
    • ネットワークは信頼できない
    • 遅延が発生する可能性があり
  • クライアントロジックに寄せられるなら寄せた方がいい
  • クライアントロジックの方が信頼できる

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~ by @izmeal2000 さん

BFFのお話。

役割

マイクロサービスの提供するAPI軍とクライアントをつなぐ中間

どんな課題を解決してるのか3つ

  • 通信パフォーマンス
  • 集約ロジックの分散
  • 些細な挙動変更にも申請が必要
    • アプリのリリースには時間がかかる

どういう機能に追加したのか

  • ポイントを貯める機能
    • 歩く
    • 食事記録
    • 写真投稿

一つの画面にいろんな機能がある

通信パフォーマンス

いろんなマイクロサービスから情報を取ってきてる BFFを挟むことで計6個のリクエストに集約できた! 集約すると→遅いAPIに引きづられる、個別のリトライができない(全部叩き直す) →適切な粒度でのAPI集約!

集約ロジック

androidiosそれぞれで書くと差異が出る→BFFにまとめる!→good!

レスポンスによる表示切り替え

実装していた仕様を消す
→それぞれでロジックを持っていると、それぞれ変更が必要
→BFFなら、BFF側を修正するだけなので3行消すだけでリリースできる!

今後の展望

ビジネス→モバイルエンジニア→サーバーエンジニア でコミュニケーションを取っていると、コミュニケーションミスが起こってしまう
基本BFFはUIチームで開発されるもの

2つの同期 4つの状態 by @ktanaka117 さん

2つの同期

  • オブザーバー同期
    • 監視によるデータの同期
    • 疎結合に同期
    • どこから同期イベントが送信するのか読みづらい
  • フロー同期
    • 手続きによる同期
    • データフローが追いやすい
    • 遠い場所にあるコンポーネント同士がデータ同期しづらい

4つのステート

  • Screen State
    • viewの状態 label.text imageView.image
  • Presentation State
    • プレゼンターの状態
    • Screen StateとSession Stateの間で管理するデータだと思う
    • Twitterのお気に入りみたいな?
  • Session State
    • モデルの状態
    • Record Stateのコピーデータ
  • Record State
    • dataStoreの状態
    • 永続化

GUIアーキテクチャを理解する

4つのステートをクリーンアーキテクチャに当てはめる

  • Screen State
  • Presentation State
    • → Presentation Layer
  • Session State
    • →Domain Layer
  • Recod State
    • → Data Layer
  • Screen StateとRecord Stateは遠い
  • state同士をつなぐパターンは様々
  • state同士をつなぐパターンがMVCとかMVPになった
  • 機能によって仕様は異なる
    • ↑機能によってパターンが分かれててもいいのでは

設計の話をする前にすり合わせしたい言葉 by @shinkuFencer さん

webとアプリエンジニアで結構認識が違うよね?意識合わせ、すり合わせ大事という話だった。 RailsやってるとActiveRecord=Modelになってしまうのはとてもわかる。

パネルディスカッション

  • テキストをサーバーから受け取る?
    • サーバーに置くと変更できる!
    • ボタンに置くテキストだと、ボタンの幅とかもサーバーに置くべき?
    • ↑どんどん増えていく
    • どうやって決めるか?→ケースバイケース!!!!
  • 申請以外にサーバーで持つメリットは?
    • 責務の視点からサーバーに置くとも言える(共通にしたいからとか)
    • クライアントで書くとなにがいいか
      • 型付けされる
      • iOSAndroidで出す文言を変える場合
  • 設計をレベルアップするためにどんなことをしているか
    • 新しい設計はだいたい書いてみてる
    • 知らないパターンのサンプルをみる
    • そのアーキテクチャが出てきた動機を調べる
      • 今までのアーキテクチャとどう違うのか
      • 差分を比較してわかりやすく早く理解できる
    • 論文を見る→乱立してるqiitaの記事に惑わされない!
    • 元ネタを知っていくと理解の速度が早まる
    • 事業が一番前に進む設計が正解
      • 1年後とかにこっちだったな〜とかある
      • 答え合わせをする、次に生かす
      • サービスの切り方
    • ビジネス要件は結構大事
      • 3~6ヶ月の短期間のものだと、アーキテクチャを使うまでもないな!すぐ終わっちゃうし!とかある
    • このパターンがどこで使えるかという精度が上げられる
    • どのパターンがどの場合に有効なのかを考えるといい設計につながる!

全体の感想

正直全然ついていけてなかった!!!

でもwebとアプリでは考えてることが違って、設計も違うんだな〜と勉強になった。
ロジックをクライアントとサーバーどっちに書くべきか?とか、
設計のスキルアップのために何をしてるとか、割とすぐ活かせそうなこともあったので行ってよかった。

あとは、BFFをちょっと知れた。
今やっている案件だとマイクロサービス化全然していないので、やろう!と思ったこともなかった。