Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SwiftUIとGraphQLでプロダクトの継続的な破壊に立ち向かう

B1702643adfb1c2216f6db6fab3e5073?s=47 たまねぎ
September 19, 2021

 SwiftUIとGraphQLでプロダクトの継続的な破壊に立ち向かう

iOSDC2021 の発表資料です

B1702643adfb1c2216f6db6fab3e5073?s=128

たまねぎ

September 19, 2021
Tweet

Transcript

  1. ɹɹ ©︎ hey, Inc SwiftUIとGraphQLで新規プロダクトの継続的な破壊に立ち向かう ヘイ株式会社 テクノロジー部門 モバイルアプリケーション本部 STORES レジ

    iOSエンジニア 横山 拓也(@_chocoyama) iOSDC2021
  2. ɹ ɹ 自己紹介 横山 拓也 Yokoyama Takuya @_chocoyama(Twitter) 2013.04 ヤフー株式会社入社 2019.12 ヘイ株式会社入社

  3. ɹ ɹ CD

  4. ɹ ɹ CD Continuous Delivery? Compact Disk? Creative Director? Career

    Development? Cash Dispenser?
  5. ɹ ɹ Continuous Destruction(継続的な破壊) ※ Ωϟονʔͩͱࢥͬͯ࢖͚ͬͨͩͰɺͲ͜ʹ΋ఆண͍ͯ͠ͳ͍ݴ༿Ͱ͢

  6. ɹ ɹ アプリケーションの継続的な破壊 改善・変更 (破壊) フィードバック Ұ౓࡞ͬͯऴΘΓͰ͸ͳ͘ɺ ৗʹ࡞ͬͨ΋ͷΛյ͠ͳ͕ΒɺΑΓྑ͍΋ͷΛ໨ࢦ͢ • UIの変更

    • APIの変更
  7. ɹ ɹ STORES レジ • 実店舗で使うPOSシステムを提供するiPadアプリ • 初期実装から変更がなかった画面はほぼ0 • 「実装→フィードバック→修正」のサイクルを

    
 何度も高速に実行 • リリースまでに少なくとも3回ほど 
 フルリニューアルしている
  8. ɹ ɹ STORES レジの概要

  9. heyが提供するSTORESプラットフォームの中の新しいプロダクト ネットショップと1つになった新しいPOSレジアプリ

  10. ɹ ɹ 主な機能 • お会計 • 決済手段管理 • 精算 •

    商品・在庫管理 • ネットショップ連携 ϨδΞϓϦ ϨγʔτϓϦϯλʔ ΩϟογϡυϩΞʔ STORES ܾࡁ୺຤ όʔίʔυϦʔμʔ
  11. ɹ ɹ 技術スタック • フレームワーク:SwiftUI, Combine • APIクライアント:Apollo-iOS(GraphQL) • SDK:STORES

    決済SDK
  12. ɹ ɹ 破壊(変更)への対応

  13. ɹ ɹ 変更に対応していく必要性 変更 Ձ஋ ࣮૷ ֬ೝ ϦϦʔε ユーザーに価値を与え続けるには、変更は避けられない ࢼߦࡨޡ

    ܧଓతͳվળ ϑΟʔυόοΫ ϑΟʔυόοΫ
  14. ɹ ɹ 変更に対応しやすい → ユーザーに価値を届けやすい 変更に対応していく必要性

  15. ɹ ɹ SwiftUI

  16. ɹ ɹ SwiftUIの強み • 宣言的シンタックスで 
 シンプルな記述ができる • Previewを活用して 


    高速にUIの確認ができる
  17. ɹ ɹ UIKitとの比較 1.レイアウト変更時の修正 2.表示の確認

  18. ɹ ɹ 1. レイアウト変更時の修正 ᶃ DescriptionϥϕϧΛ࡟আ ᶄ Ձ֨දࣔͷฒͼͱҐஔมߋ

  19. ɹ ɹ UIKit + AutoLayout 1.不要なViewを削除 2.Viewが消えたことによる不整合を修正 3.位置変更するViewのAutoLayout貼り直し 4.Outlet接続関連のコードを削除 ࡟আ

    Ҡಈ
  20. ɹ ɹ SwiftUI ① 削除 ② VStackの 外に移動 ③ HStackを削除、

    Textの順番を逆に Before After
  21. ɹ ɹ レイアウト変更のしやすさ UIKit+AutoLayout SwiftUI 依存ファイル 多い 少ない 修正ステップ 複雑

    単純 安全性 クラッシュの恐れ コンパイラで保証 特有のスキルが必要 素早く安全に対応可能
  22. ɹ ɹ 表示の確認 •「UIの変更→表示確認」のサイクルの速さは、開発効率に直結する •複数の表示パターンがあるUIの場合、特に確認コストがかかる

  23. ɹ ɹ なんか違う… UIKit + AutoLayout •表示が実行時と異なる場合がある •確認はアプリを起動して対象画面に遷移する •1度に1パターンしか確認できない •修正と起動のサイクルを繰り返す可能性がある

    このパターン はOK 全部確認 できた! मਖ਼ɾىಈ मਖ਼ɾىಈ मਖ਼ɾىಈ
  24. ɹ ɹ SwiftUI + Xcode Preview •アプリの起動が必要ない •修正内容が即時で確認できる •任意の状態を再現したPreviewの実装を残せる •実装とPreviewを1対多の状態にできる

    •(コードだけでも表示イメージがしやすい) 一気に 全部確認 できた! मਖ਼ɾىಈ
  25. ɹ ɹ SwiftUI + Xcode Preview

  26. ɹ ɹ 表示確認のしやすさ UIKit+AutoLayout SwiftUI アプリの起動 必要あり 必要なし パターンごとの確認 毎回起動

    1度のPreview実行 継続的な利用 できない できる 高コスト 低コスト
  27. ɹ ɹ デザインシステムに則った 共通UIライブラリを作成 STORES レジでの変更への取り組み •デザインチームが独自のデザインシステムを構築 •アプリデザインはこれをベースに画面設計 変更に耐え得る 仕組みとして

  28. ɹ ɹ デザインシステム = デザイン原則をまとめたスタイルガイドやその実装などの仕組み 以下のような価値を生む • 一貫性のあるIFでユーザー体験を向上 • デザイナーとエンジニア間の共通言語を確立

    • 局所最適されたデザインを抑制し、デザイン・開発コストを削減 デザインシステムとは
  29. ɹ ɹ 共通UIコンポーネントの例 ※ Preview༻ͷViewΛ࣮ߦ࣌ʹݺͼग़ͯ͠ɺUIΧλϩάͷΑ͏ͳػೳΛ࡞͍ͬͯ·͢

  30. ɹ ɹ •汎用的に使えるUIを切り出し •→ 切り出し単位はデザインシステムに合わせるだけ •デザイナーとエンジニアの画面構築工程が揃う •→ パーツを組み合わせるだけで画面ができる •アプリ内 SwiftPackageManager

    で対象コンポーネントを管理 •→ 依存の切り出し •→ ビルドやPreview実行の高速化 共通UIライブラリの作成 σβΠϯγεςϜʢ໊শඇެ։ʣ σβΠϯγεςϜʢ໊শඇެ։ʣ
  31. ɹ ɹ 実装 σβΠϯ γεςϜ໊ දࣔύλʔϯΛ PreviewͰ໢ཏ σβΠϯ γεςϜ໊ σβΠϯ

    γεςϜ໊ σβΠϯ γεςϜ໊ σβΠϯ γεςϜ໊ σβΠϯ γεςϜ໊ ※ σβΠϯγεςϜ໊͸ඇެ։
  32. ɹ ɹ 利用 σβΠϯ γεςϜ σβΠϯ γεςϜ σβΠϯ γεςϜ →

    UI作成のコストが激減 σβΠϯ γεςϜ σβΠϯ γεςϜ σβΠϯ γεςϜ σβΠϯ γεςϜ
  33. ɹ ɹ •レイアウトの変更が容易 
 → 壊しては作るといった繰り返しを気軽にできる •UIの表示確認を効率的にできる 
 → 実装スピードが上がるだけでなく、継続的なメンテナンスにも活用できる

    SwiftUIの変更しやすさ UI関連の変更にコストがかからない
  34. ɹ ɹ GraphQL

  35. ɹ ɹ GraphQLとは •API用のクエリ言語 •スキーマによってIFの型が厳密に決まっている

  36. ɹ ɹ REST APIとの比較 GraphQL REST 型付け 強い 弱い エンドポイント

    1つ 複数 取得リクエスト Query GET 更新リクエスト Mutation POST/PUT/ PATCH/DELETE
  37. ɹ ɹ GraphQLの強み 1.取得するデータをクライアントが決められる 2.少ないリクエストで複数のリソースにアクセスできる

  38. ɹ ɹ 1. 取得するデータをクライアントが決められる ϦΫΤετ Ϩεϙϯε Ұ୴શσʔλΛऔಘͯ͠ɺඞཁͳ΋ͷ͚ͩ࢖͏ → 必要なデータだけ取得する

  39. ɹ ɹ 2. 少ないリクエストで複数のリソースにアクセスできる Φʔμʔৄࡉը໘ アイテム情報 を追加したい

  40. ɹ ɹ REST API の場合 Orders Items APIリクエストが増える Orders itemIds

  41. ɹ ɹ REST API の場合 Orders Items APIリクエストが増える Orders itemIds

    追加の通信処理が必要になり、実装が複雑化する OrdersAPIͷ݁ՌΛݩʹɺ ItemsAPIΛୟ͖௚͢ OrdersAPIΛୟ͚ͩ͘
  42. ɹ ɹ GraphQL の場合 Orders Items APIリクエストが増えない Orders itemIds

  43. ɹ ɹ GraphQL の場合 Orders Items APIリクエストが増えない Orders itemIds 取得したいデータを追加で指定するだけ

  44. ɹ ɹ GraphQL の場合 Orders Items APIリクエストが増えない Orders itemIds 取得できるデータが増えるだけ

  45. ɹ ɹ GraphQL の場合 Orders Items APIリクエストが増えない Orders itemIds 同時に複数のQueryを投げられる

  46. ɹ ɹ STORES レジでの変更への取り組み 1.APIに変更が入ったことの自動検知(独自実装) 2.APIのIFとなるSwiftコードの自動生成(Apollo-iOSの機能を活用)

  47. ɹ ɹ 1. APIに変更が入ったことの自動検知(独自実装) Appエンジニア 想定したデータが取得できません BEエンジニア ドキュメントの更新漏れてました BEエンジニア API完成しました

    Appエンジニア APIがエラーになります BEエンジニア 変更の共有忘れてました 人力での変更管理には限界がある ケース1 ケース2
  48. ɹ ɹ 1. APIに変更が入ったことの自動検知(独自実装) 旧スキーマ ファイル 新スキーマ ファイル App BE

    旧スキーマ ファイル 新スキーマ ファイル ࠩ෼νΣοΫ 自動でSlackに変更通知 →共有漏れや不正な定義の参照を防ぐ GitHub Bitrise
  49. ɹ ɹ 2. APIのIFとなるSwiftコードの自動生成(Apollo-iOSの機能を利用) スキーマ ファイル BE クエリ ファイル スキーマ

    ファイル ੩తղੳ Swiftコードを自動生成 →BEとAppでAPI定義が同期される Local Apollo GitHub
  50. ɹ ɹ •取得したいデータが増えても「追加リクエスト不要」で「IFの型が自動生成される」 
 → 意図した変更に対応しやすい •API側の変更をシステム的に追従可能なので、人力のコミュニケーションに頼る必要がない 
 →意図していない変更にも対応しやすい データ関連の変更にコストがかからない

    GraphQLの変更しやすさ
  51. ɹ ɹ •SwiftUIを利用 → UI関連の変更にコストがかからなくなる •GraphQLを利用 → データ関連の変更にコストがかからなくなる SwiftUIとGraphQLのまとめ ユーザーに価値を届けやすくなる

    変更に対応しやすくなる
  52. ɹ ɹ SwiftUI + GraphQL

  53. ɹ ɹ •Viewとセットで、必要なデータをQuery(Fragment)で用意する •UIレイアウトと参照データの定義を1対1で宣言しておく(データ取得も宣言的に行う) •SwiftUIのリアクティブなレンダリング機構と、 
 Apollo-iOSのコード生成+キャッシュ機構を組み合わせて実現 •レイアウト定義とGraphQL定義で実装がほぼ完結する Fragment Colocation(的なこと)

    ※ STORES ϨδͰ͸ಋೖ͍ͯ͠·ͤΜ
  54. ɹ ɹ サンプル画面

  55. ɹ ɹ 必要な実装コードのすべて SwiftUI GraphQL 1ର1

  56. ɹ ɹ 必要な実装コードのすべて データの 参照 Query Mutation SwiftUI GraphQL 1ର1

  57. ɹ ɹ 実装サンプル(取得データの反映) 1. Queryを発行 →内部キャッシュが変更されると自動呼び出し 2. 再レンダリング 3. 状態に応じた表示

  58. ɹ ɹ 実装サンプル(データの更新) 2. キャッシュの更新を検知 (Queryでオーダーノートを参照→それが更新されると呼び出される) 1. Mutationを発行 (オーダーノートを更新) 3.

    再レンダリング 4. オーダーノートの更新
  59. ɹ ɹ 実装サンプル データとUIが同期された状態に

  60. ɹ ɹ PreviewでのAPIのモック Previewでのみ、 カスタムのEnvironmentValueをセット

  61. ɹ ɹ Continuous Destruction(継続的な破壊)

  62. ɹ ɹ •SwiftUI •度重なる変更に対して、UIKitでは実現できないスピードで対応を進められた •OSバージョンの変更に対してはまだ弱い •デザインシステムの実装で開発が効率化したが、デザインシステム自体への変更対応は現状最適化できていない •GraphQL •要件や仕様の変更によって、API実装部分が壊れることがほとんどなかった •自動化の仕組みにより、変更に安全に追従していくことができた •開発フローも含めた最適化なども検討していきたい(スキーマファースト開発など)

    振り返り と 今後の展望
  63. ɹ ɹ ありがとうございました! SwiftUIと GraphQL最高!