miyashi.app

8/26

2023

[GraphQL] Apollo-iOS を使ってみて感じたイケてるところ。イケてないところ。

#GraphQL#Xcode#Apollo-iOS

[GraphQL] Apollo-iOS を使ってみて感じたイケてるところ。イケてないところ。 という記事を過去に書きました。
https://qiita.com/po_miyasaka/items/d41dd6c027155e584aeb

GraphQL の真髄について思ったこと

後日 iOSDC の以下の発表を拝見しました。
宣言的 UI の状態管理とアーキテクチャ - SwiftUI と GraphQL による実践 by そな太

こちらの発表によると GraphQL の思想として GraphQL のオブジェクトは View から由来して定義されるべきでそのオブジェクトは View 側まで import されて使われるべきということでした。 このメリットはデータと View が完全一致して検討事項が減り、完全に宣言的になるとのことです。

正直なかなか革命的で衝撃でした。将来的な理想の形に近いものであると感じますが、
現時点の私の考えとしては以下のようなデメリットがあると思いました。

  • API の細かい変更でも UI のコードが変わる。
  • 地味にプロパティへのアクセスの仕方がめんどくさい(例: data.todo.fragments.tasksFragments)
    • この複雑さ故にテストをするのは難しい。
  • 自動生成されたデータの変換作業をしたいときに、各オブジェクトの extension として書くことができない。変更用 Utility を書くとしても自動生成で型が安定しないのでやりづらくそれであれば別にオブジェクトを定義したい。
  • Apollo がサポートされなくなった場合や通信方法を変更した場合、アプリ全体のコードの修正が必要となる。

GraphQL 駆動はアプリを API 情報を表示するただのクライアントとして扱うのであればいいかもしれません。これはサーバー&クライアンツが完璧に連携が取れており、お互いを完璧に把握している状態、もしくはクライアント側のエンジニアが自由に API 側を作成できる環境であれば可能だと思います。ただ、既存の大きいプロダクトはこの判断は難しいと思いました。