Server-Driven UI入門: 画面のStateを直接受け取るアプローチ

【iOSDC2024 day0 19:20 track D】
Server-Driven UI入門: 画面のStateを直接受け取るアプローチ
https://fortee.jp/iosdc-japan-2024/proposal/1f93f00d-02ba-4a5a-8554-c69e7baef816

SwiftUIの登場によって、画面のStateを使ってUIを構築するState-Drivenなアプローチが可能になりました。
クライアントでは、バックエンドからいくつかのAPIをコールし、それらを組み合わせて画面のStateを構成し、SwiftUIのViewに渡すことでUIを表示することができます。

では、画面に一つのAPIで画面のStateをそのまま受け取れる場合、クライアント側にはどのようなロジックが残るでしょうか？
if文やSwitch文のような分岐を持たないアプリは実現できるのでしょうか？

本トークでは、BFF（Backend for Frontend）と呼ばれるクライアント用の中間サーバーを活用し、
可能な限りロジックをバックエンドに寄せたServer-DrivenなUI構築を実務で取り組んだ経験を通して

要件に合わせたResponse構成の工夫
Server-DrivenなUI構築が上手くハマる具体的な事例
といった、クライアントが可能な限りプレゼンテーションロジック以外を持たない構成とその活用について紹介します。

さらに、本トークでは実際にBFFの導入が難しい方に対しても、極端な事例を通じて

どこまでのロジックをバックエンドで持つべきか
バックエンドとのシステム境界をどう考えるべきか
といった疑問への一つの指針を提供します。

Transcript

1. Server-Driven UIೖ໳
   ը໘ͷStateΛ௚઀ड͚औΔΞϓϩʔν nade @iOSDC 2 024 day 0
2. nade • CyberAgent iOS Next Experts • tapple iOS Group Leader @kazuma_nagano
3. 今 日 のテーマ Server-Driven UI 🤔 サーバーからUIが 返ってくるの？ HTMLをSwiftUIに パースする話？ React Native？ PWAっぽい話？
4. 今 日 のテーマ Server-Driven UI 🤔 サーバーからUIが 返ってくるの？ HTMLをSwiftUIに パースする話？ React Native？ PWAっぽい話？ ❌ ❌ ❌
5. 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
6. そんなあなたにServer-Driven UI • 「施策ごとのUI開発がとにかく 大 変、 バックエンドの変更だけで機能リリースできればなー」 • 「ビジネスロジックの実装がiOSとAndroidでずれちゃう、 保守しやすい管理 方 法はないだろうか？」 • 「クライアントの設計が複雑で負債化してしまっている、 クライアントのロジック量を減らせないだろうか？」 https://github.com/csmets/Server-Driven-UI
7. 1 .【 入門 編】Server-Driven UIとは 2 .【番外編】普段の開発にどう活かすか？ 3 .【応 用 編】軽量Server-Driven UI 4 . まとめ
8. 【 入門 編】Server-Driven UIとは
9. 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
10. 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 /
11. 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
12. 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
13. その他 Server-Driven UIについて（Web中 心 ）よくまとまっているリポジトリ https://github.com/csmets/Server-Driven-UI
14. コアとなる共通のコンセプト 事前定義されたUIコンポーネントの • layout構成 • UI ComponentごとのState • Action をサーバーから返却しそのまま表 示
15. "screens": [ { "id": "ROOT", "layout": { "wide": {}, # landscape mode "compact": { # portrait mode "type": "SingleColumnLayout", # ϨΠΞ΢τͷछྨ "main": { "type": "MultipleSectionsPlacement", "sectionDetails": [ # ը໘ཁૉͷsectionIdͷΈ { "sectionId": "hero_section" }, { "sectionId": "title_section" } ] }, } } }, ] layout構成
16. "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
17. SwiftUI時代のServer-Driven UI
18. SwiftUI時代のServer-Driven UI 今まで • スキーマ ↔︎ UIコンポーネント間のデータバインディングのコスト • UIコンポーネントごとのStateの設計コスト SwiftUI時代 • State ↔︎ UI がシームレスに変換可能に • SwiftUI.ViewがそのままUIコンポーネントのStateとして利 用 可能
19. SwiftUI.ViewはstructなのでCodable準拠可能 State ↔︎ UI のシームレス変換 Codable
20. JSONからView階層まで直接デコード可能 State ↔︎ UI のシームレス変換 Codable SwiftUI
21. Server-Driven UIのメリット • リリース不要で変更可能なため 高 速 画 面 構成の変更にアプリの審査やリリースが不要 • ビジネスロジックを各プラットフォームで持たない 変更容易性を 高 く保つ システム全体を通じたDRY原則の徹底 • クライアントロジックがコンパクトに 本来の責務であるユーザー体験に集中できる サーバーへのリクエストも 大 幅に減るためパフォーマンス向上にも
22. Server-Driven UIのデメリット • 事前のUIコンポーネント定義や基盤構築が 大 変 そこに 工 数を割くことのできる 大 きなチームが取り組んでいる • 膨 大 なUIコンポーネントの組み合わせに対するQAコスト • クライアント-バックエンドの間を埋めるスキルが必要 例）中間サーバーをクライアントエンジニアが書く (Backend for Frontend: BFF) 例）クライアントのUIコンポーネントのStateに責務を持つバックエンド
23. 【番外編】普段の開発にどう活かすか？
24. Server-Driven UI導 入 したくなった 人 ？🙋
25. 【番外編】普段の開発にどう活かすか？ • これまでを踏まえてサーバー ↔︎ クライアント間の責務の問題を考えてみる Server-Driven UIはサーバーにビジネスロジックやUIロジックの責務を押し付けた極論 • どんなAPIレスポンスを定義しますか？
26. どんなAPIレスポンスを定義しますか？ ①Client-Driven に作る場合 ユースケース層 プレゼンテーション層 サーバー ユーザー 課 金
27. どんなAPIレスポンスを定義しますか？ ①Server-Driven UIの場合 サーバー クライアント
28. どんなAPIレスポンスを定義しますか？ ①Server-Driven UIの場合 レスポンスを作るまでにはバックエンド側にユースケース層にあたるロジックがある 中間サーバー クライアント マイクロサービス ユーザー 課 金
29. Server-Driven UIはシステムの境界を どこに引くか？の差と捉えることができる
30. 参考: バックエンドを別システムとして捉える https://speakerdeck.com/akkyie/abema-mobile-architecture-ca-dot-swift-number- 1 8
31. 参考: バックエンドを同じシステムとして捉える https://speakerdeck.com/akkyie/abema-mobile-architecture-ca-dot-swift-number- 1 8
32. システムの要件に合わせてさらに グラデーションを考えられるかも 🤔
33. 【応 用 編】軽量Server-Driven UI
34. レイアウト、コンポーネントデータ、アクションなどをサーバーに移譲 Server-Driven UI おさらい
35. • 軽量SDUI 軽量DDDのようにすべてのロジックを移譲するわけでなく、システムの運 用 可能性の 高 い ものを移譲する • SDUIの機能の全部はいらないことが多い 例）同じ機能のレイアウトを頻繁に変えるケースがあるか？ • クライアントの特定のロジックのみ移譲する 例）レイアウトはクライアント、コンポーネントのStateを直接JSONで受け取る 軽量Server-Driven UI
36. システムの品質特性を考える 事業やシステム上で重要な品質特性に合わせて、適切に責務を移譲すべき ISOの公開しているソフトウェア品質特性の例 https://iso 2500 0 .com/index.php/en/iso- 250 0 0 -standards/iso- 25 010
37. タップルの場合 例）タップルにおける重要な品質特性 • モジュール性 カードのフリック、ユーザー検索、メッセージ、ビデオチャットなど機能の幅が広い → Featureごとに移譲するロジックの度合いを決めるべき • 検証容易性 A/B Testing 等早い仮説検証を繰り返すことが施策開発において重要 → A/B の分岐が クライアントにある場合（Firebase など）レイアウトはクライアントで決定 • 保守容易性 サービスの特性上クライアント側がボトルネックになったり 手 戻りするケースが多い →ロジックをバックエンドにある程度移譲した 方 が、トータルの保守容易性は下がる
38. 例）検索機能における軽量SDUI • 画 面 のレイアウト情報はクライアントのまま • SwiftUI.Viewに定義されたStateをそのまま バックエンドから受け取る • バナー等の運 用 のある 面 のみインタラクションを バックエンドで決定 軽量SDUI の実践①
39. 例）課 金 機能における軽量SDUI • 画 面 のレイアウト情報をクライアントで可変に • 同 一 のStateで複数種類の画 面 を 表現できるように 軽量Server-Driven UI の実践② ユーザーA ユーザーB 課 金 ViewのState
40. まとめ
41. まとめ • Server-Driven UIの歴史とコアなコンセプトの紹介 レイアウト、コンポーネントデータ、アクションなどをサーバーに移譲 • Server-Driven UIを題材にバックエンド ・ クライアント間のシステム境界の 考え 方 • 軽量 SDUI を通じてプロダクトの特性にあった運 用 の 手 法