既存プロダクトにGraphQLを導入する際に心がけておくべきポイント.

既存プロダクトにGraphQLを導入する際に
心がけておくべきポイント

自己紹介
・森友佑
・株式会社サイバーエージェント
・AmebaLIFE事業本部
・Amebaブログ作ってます

既存プロダクトにGraphQLを導入する際に
心がけておくべきポイント
GraphQLのメリットを
活かす・殺さない実装を意識すること

GraphQLのメリットって何？

事前に調べてもメリットが多すぎて逆に分かりづらい

一言で表現してしまうと👇
コード量・すり合せ時間が減り、
開発工数の大幅削減につながる
但し、既存アーキテクチャとの組合せ方によっては、
そのメリットが消えてしまうかも・・・

Githubクライントサンプルアプリで実装比較してみる
GraphQLフル活用
既存アーキ準拠

Github のRepositoryを表示・更新するアプリで比較
戻る操作で最新の
descriptionを反映
Description変更
Repository情報表示

Apollo Kotlinを活用して開発する
https://www.apollographql.com/docs/kotlin

既存のアーキテクチャと組み合わせるパターン

Guide to app architecture
既存アーキテクチャ = Guide to app architecture※1
と仮定する
※1 https://developer.android.com/topic/architecture

アーキテクチャ図(GraphQLをData層で閉じるパターン例)
モデル毎にリポジトリを区切るため、
1 requestにまとめられない
クラス変換コードが多い

画面観状態同期実装
戻る操作で最新の
descriptionを反映
Description変更
Repository情報表示
��

画面間状態同期 (値引き回しパターン)
AModel表示
(Page1)
AModel更新操作
(Page2)
更新値をcallbackで前画面に渡す

画面間状態同期 (共通ViewModelパターン)
activityViewModels
or
navGraphViewModels

画面間状態同期 (Repositoryパターン)
Page1ViewModel Page2ViewModel
ARepository
(Repository内部で最新値をFlowでキャッシュし、リアルタイムで通知する)
AModelFlowを
subscribe AModel更新
Flow経由で
最新値をemit

GraphQLフル活用パターン

アーキテクチャ図(GraphQLフル活用例)

Query・Mutation呼び出しだけで、画面間を跨ぐ状態同期まで完結
ApolloStore
GraphQLレスポンスを正規化してキャッシュ
Page1ScreenQuery
をWatch
UpdateModelMutation実行
正規化されたキャッシュが更新され、
更新結果が前画面にも自動的に反映される
①
②
③
④
⑤
画面遷移
戻る操作

※自動生成
アーキテクチャ比較
※自動生成
GraphQLフル活用
既存アーキ準拠

GraphQLフル活用例詳細
※実装詳細は、👇を参照ください
https://github.com/YusukeMoriJapan/github-client-kotlin

UIコンポーネントが欲しい情報を、Fragmentとしてスキーマに定義
Fragment = 複数のクエリやミューテーションで再利用できるフィールドのセット
Schema
UI Component

FragmentからUIモデルが自動生成される
・UI Component用のモデルを手書きする手間なし
・リクエストを書き換えると、自動的に
Componentが参照するクラスも書き換わる
※fragmentでピックアップしたフィールド =
リクエストするフィールド

画面単位でQueryを書く
・画面の構造とQueryの構造を一致させる
(Queryの中にFragmentを入れる)
・UI Componentが要求するフィールド(Fragmentのフィールド)が
変わると、Queryも連動して変更される
・Fragment変更だけで、UIとネットワークリクエストの要求フィールド変更まで完結
Screen名 = Query名

Composable関数内で直接Queryをcollectする (実装例1)
戻る操作や画面回転で再度画面を
描画する時は、キャッシュ優先で取得
※isRestoredの詳細は、サンプルコードを見てください
リクエストをFlowで受け取り、
Stateに変換

Composable関数内で直接Queryをcollectする (実装例2)
※1 https://github.com/takahirom/Rin
Rin※1を活用し、
Composeのライフサイクルを跨いで
(ConﬁgrationChangeや、画面遷移を跨いで)
Flowを保持する

自動生成クラス(Fragment)
をそのまま
UI Componentに渡す
UI Componentへの値渡し
・Component用のデータ構造体(Fragment)が
レスポンスに自動で含まれる。
・ Componentへの煩雑な引数リレーが
無くなる

Mutationの定義(Descriptionの更新)
キャッシュ更新のため、
更新結果をレスポンスに含める
※理由は後述

Mutationの実行(Descriptionの更新)
レスポンスを待たずにキャッシュを更新する

必要コードは以上
※細かい実装は省いてます

Query・Mutation呼び出しだけで、画面間を跨ぐ状態同期まで完結
ApolloStore
GraphQL のレスポンスを正規化して(モデル単位で)キャッシュ
Page1ScreenQuery
をWatch
UpdateModelMutation実行
正規化されたキャッシュが更新され、
更新結果が前画面にも自動的に反映される
①
②
③
④
⑤
画面遷移
戻る操作

キャッシュ更新イベントは連鎖的に伝わる
参照
参照
伝搬
伝搬
Repository
RepositoryOwner
PageQuery
参照
伝搬
UI
Mutation/Query Response
キャッシュ更新
hogehoge@email.com

(補足)Preview対応
Previewできるように、ApolloClientの依存を外す

GraphQLフル活用で達成できたこと
・UI/通信構築に必要なクラスの多くを自動生成でまかなえるように
・複雑な状態管理(クラサバor画面間状態同期)コードを書く必要が無くなった
・データソースの隠蔽(Cache or Networkの判断)も
Apollo Clientがカバーしてくれる
が・・・・

以下前提条件が全て揃っていないとフル活用はできない
・ビジネスロジックが全てバックエンド側で閉じている
(UseCase層までバックエンド側まで含んでいるとも言える)
・Mutationのレスポンスに変更後の値が確実に返ってくる
(レプリ遅延が発生しないか？)
・既存のアーキテクチャを全て刷新する工数が確保できている
(刷新工数に見合うリターンはあるか？)
・GraphQL以外のデータソース(REST API・ローカルDB等)が存在しない

GraphQL導入前に最適解を見つけよう
・GraphQL導入によって何を達成したいのかを明確にする。
・スキーマベースの開発ができるだけでも価値があると判断するのであれば、
既存アーキテクチャを大幅刷新する必要はないかもしれない
・プロダクトで複雑なロジックをアプリ内でどれだけ持っている
(持たせる必要がある)のかを把握する。
・そのほとんがバックエンド側にあるorこれから移すプランがあるかつ、
バックエンド含むプロダクト全体で、GraphQLフル活用の方針が固まっているか？
・前ページ前提条件が満たせない場合、アプリ内で責務の分離を実現しつつ、
GraphQLのメリットも両立させる方法を模索する。
最後に両立案を紹介します
👉

両立案1 Pageで分ける
GraphQL完結Page
GraphQLで完結しないPage

両立案1 Pageで分ける
GraphQL完結Page
GraphQLで完結しないPage
状態同期コード削減 ◎
手書きクラス削減 ◎
fetch回数削減 ◎
一貫性 △

両立案2 参照系と更新系で分ける (Page単位 x Business Model単位)

両立案2 参照系と更新系で分ける (Page単位 x Business Model単位)
状態同期コード削減 ◎
手書きクラス削減 △
fetch回数削減 ◎
一貫性 ◯

以上です
※GraphQLフル活用実装詳細は、👇を参照ください
https://github.com/YusukeMoriJapan/github-client-kotlin

既存プロダクトにGraphQLを導入する際に心がけておくべきポイント.

More Related Content

Similar to 既存プロダクトにGraphQLを導入する際に心がけておくべきポイント. (20)

既存プロダクトにGraphQLを導入する際に心がけておくべきポイント.