Server-Driven UIೖ໳ ը໘ͷStateΛ௚઀ड͚औΔΞϓϩʔν nade @iOSDC 2 024 day 0

nade • CyberAgent iOS Next Experts • tapple iOS Group Leader @kazuma_nagano

今 日 のテーマ Server-Driven UI 🤔 サーバーからUIが 返ってくるの？ HTMLをSwiftUIに パースする話？ React Native？ PWAっぽい話？

今 日 のテーマ Server-Driven UI 🤔 サーバーからUIが 返ってくるの？ HTMLをSwiftUIに パースする話？ React Native？ PWAっぽい話？ ❌ ❌ ❌

Server-Driven UIって？ • Server側からUIの構成をそのまま受け取り描画する 「What if clients didn’t need to know they were even displaying a listing? 」 クライアント 自身 がリストを表 示 していることさえ知る必要がないとしたら？ • 2021年のAirBnbの記事で提案された開発 手 法で話題に 他にもSpotify、Expedia、Lyftなどで導 入 実績 https://github.com/csmets/Server-Driven-UI

そんなあなたにServer-Driven UI • 「施策ごとのUI開発がとにかく 大 変、 バックエンドの変更だけで機能リリースできればなー」 • 「ビジネスロジックの実装がiOSとAndroidでずれちゃう、 保守しやすい管理 方 法はないだろうか？」 • 「クライアントの設計が複雑で負債化してしまっている、 クライアントのロジック量を減らせないだろうか？」 https://github.com/csmets/Server-Driven-UI

1 .【 入門 編】Server-Driven UIとは 2 .【番外編】普段の開発にどう活かすか？ 3 .【応 用 編】軽量Server-Driven UI 4 . まとめ

【 入門 編】Server-Driven UIとは

Server-Driven UIのコンセプト 設計思想の中 心 となった3つの発表 ・ 記事を紹介 • WWDC 2 010 : Building a Server-Driven User Experience • Spotify 20 16 : Backend-driven native UI • AriBnB 20 2 1 : A Deep Dive into Airbnb’s Server-Driven UI System https://github.com/csmets/Server-Driven-UI

Server-Driven UIの歴史① WWDC 2 010 「Building a Server-Driven User Experience 」で 言 及 • UI Componentのプロパティをそのまま返却して柔軟性をあげよう • コンポーネントのステートを動的に扱うための dataType フィールド https://nonstrict.eu/wwdcindex/wwdc 2 010 / 1 1 7 /

Server-Driven UIの歴史② Spotify 20 16 「Backend-driven native UI 」 • クライアントに定義済みのコンポーネントにバックエンドが返すStateを反映 • OSSでおよそ150のコンポーネントとスキーマのセットを公開 https://atscaleconference.com/videos/backend-driven-native-uis/ https://github.com/spotify/HubFramework

Server-Driven UIの歴史③ AirBnB 20 2 1 「A Deep Dive into Airbnb’s Server-Driven UI System 」 • すべての機能 ・ 画 面 を表現可能なユニバーサルなスキーマを定義 レイアウト情報を持ったscreensと各UIコンポーネントのステートを持ったsections に統 一 https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system- 84 224 4 c 5 f 5

その他 Server-Driven UIについて（Web中 心 ）よくまとまっているリポジトリ https://github.com/csmets/Server-Driven-UI

コアとなる共通のコンセプト 事前定義されたUIコンポーネントの • layout構成 • UI ComponentごとのState • Action をサーバーから返却しそのまま表 示

"screens": [ { "id": "ROOT", "layout": { "wide": {}, # landscape mode "compact": { # portrait mode "type": "SingleColumnLayout", # ϨΠΞ΢τͷछྨ "main": { "type": "MultipleSectionsPlacement", "sectionDetails": [ # ը໘ཁૉͷsectionIdͷΈ { "sectionId": "hero_section" }, { "sectionId": "title_section" } ] }, } } }, ] layout構成

"sections": [ { "id": "toolbar_section", "sectionComponentType": "TOOLBAR", "section": { "type": "ToolbarSection", "nav_button": { "onClickAction": { # λοϓ࣌ͷΞΫγϣϯ "type": "NavigateBack", "screenId": "previous_screen_id" } } } }, { "id": "hero_section", "sectionComponentType": "HERO", "section": { "type": "HeroSection", "images": [ # HeroSectionίϯϙʔωϯτͷStateɺtype͝ͱʹܕ͕ҧ͏ "api.hoge.com/...", ], } }, UI ComponentのState ・ Action

SwiftUI時代のServer-Driven UI

SwiftUI時代のServer-Driven UI 今まで • スキーマ ↔︎ UIコンポーネント間のデータバインディングのコスト • UIコンポーネントごとのStateの設計コスト SwiftUI時代 • State ↔︎ UI がシームレスに変換可能に • SwiftUI.ViewがそのままUIコンポーネントのStateとして利 用 可能

SwiftUI.ViewはstructなのでCodable準拠可能 State ↔︎ UI のシームレス変換 Codable

JSONからView階層まで直接デコード可能 State ↔︎ UI のシームレス変換 Codable SwiftUI

Server-Driven UIのメリット • リリース不要で変更可能なため 高 速 画 面 構成の変更にアプリの審査やリリースが不要 • ビジネスロジックを各プラットフォームで持たない 変更容易性を 高 く保つ システム全体を通じたDRY原則の徹底 • クライアントロジックがコンパクトに 本来の責務であるユーザー体験に集中できる サーバーへのリクエストも 大 幅に減るためパフォーマンス向上にも

Server-Driven UIのデメリット • 事前のUIコンポーネント定義や基盤構築が 大 変 そこに 工 数を割くことのできる 大 きなチームが取り組んでいる • 膨 大 なUIコンポーネントの組み合わせに対するQAコスト • クライアント-バックエンドの間を埋めるスキルが必要 例）中間サーバーをクライアントエンジニアが書く (Backend for Frontend: BFF) 例）クライアントのUIコンポーネントのStateに責務を持つバックエンド

【番外編】普段の開発にどう活かすか？

Server-Driven UI導 入 したくなった 人 ？🙋

【番外編】普段の開発にどう活かすか？ • これまでを踏まえてサーバー ↔︎ クライアント間の責務の問題を考えてみる Server-Driven UIはサーバーにビジネスロジックやUIロジックの責務を押し付けた極論 • どんなAPIレスポンスを定義しますか？

どんなAPIレスポンスを定義しますか？ ①Client-Driven に作る場合 ユースケース層 プレゼンテーション層 サーバー ユーザー 課 金

どんなAPIレスポンスを定義しますか？ ①Server-Driven UIの場合 サーバー クライアント

どんなAPIレスポンスを定義しますか？ ①Server-Driven UIの場合 レスポンスを作るまでにはバックエンド側にユースケース層にあたるロジックがある 中間サーバー クライアント マイクロサービス ユーザー 課 金

Server-Driven UIはシステムの境界を どこに引くか？の差と捉えることができる

参考: バックエンドを別システムとして捉える https://speakerdeck.com/akkyie/abema-mobile-architecture-ca-dot-swift-number- 1 8

参考: バックエンドを同じシステムとして捉える https://speakerdeck.com/akkyie/abema-mobile-architecture-ca-dot-swift-number- 1 8

システムの要件に合わせてさらに グラデーションを考えられるかも 🤔

【応 用 編】軽量Server-Driven UI

レイアウト、コンポーネントデータ、アクションなどをサーバーに移譲 Server-Driven UI おさらい

• 軽量SDUI 軽量DDDのようにすべてのロジックを移譲するわけでなく、システムの運 用 可能性の 高 い ものを移譲する • SDUIの機能の全部はいらないことが多い 例）同じ機能のレイアウトを頻繁に変えるケースがあるか？ • クライアントの特定のロジックのみ移譲する 例）レイアウトはクライアント、コンポーネントのStateを直接JSONで受け取る 軽量Server-Driven UI

システムの品質特性を考える 事業やシステム上で重要な品質特性に合わせて、適切に責務を移譲すべき ISOの公開しているソフトウェア品質特性の例 https://iso 2500 0 .com/index.php/en/iso- 250 0 0 -standards/iso- 25 010

タップルの場合 例）タップルにおける重要な品質特性 • モジュール性 カードのフリック、ユーザー検索、メッセージ、ビデオチャットなど機能の幅が広い → Featureごとに移譲するロジックの度合いを決めるべき • 検証容易性 A/B Testing 等早い仮説検証を繰り返すことが施策開発において重要 → A/B の分岐が クライアントにある場合（Firebase など）レイアウトはクライアントで決定 • 保守容易性 サービスの特性上クライアント側がボトルネックになったり 手 戻りするケースが多い →ロジックをバックエンドにある程度移譲した 方 が、トータルの保守容易性は下がる

例）検索機能における軽量SDUI • 画 面 のレイアウト情報はクライアントのまま • SwiftUI.Viewに定義されたStateをそのまま バックエンドから受け取る • バナー等の運 用 のある 面 のみインタラクションを バックエンドで決定 軽量SDUI の実践①

例）課 金 機能における軽量SDUI • 画 面 のレイアウト情報をクライアントで可変に • 同 一 のStateで複数種類の画 面 を 表現できるように 軽量Server-Driven UI の実践② ユーザーA ユーザーB 課 金 ViewのState

まとめ

まとめ • Server-Driven UIの歴史とコアなコンセプトの紹介 レイアウト、コンポーネントデータ、アクションなどをサーバーに移譲 • Server-Driven UIを題材にバックエンド ・ クライアント間のシステム境界の 考え 方 • 軽量 SDUI を通じてプロダクトの特性にあった運 用 の 手 法