ダラーっと tweet してたもののまとめ
Android で native = Apollo Kotlin を client library として使う想定で書いている。他の cross-platform な開発環境 (React Native とか Flutter) だと事情は異なる、はず (経験ないので)。
Android アプリでバックエンド GraphQL あんま嬉しくないなと思いながら組み立ててるけど何か間違っているのだろうか
— nash (@nashcft) February 22, 2022
結局 Apollo Kotlin への依存をどこまで許容するかって話なのだろうか、単なる GraphQL client と思っているものへの依存があらゆるところに発生するのが気持ち悪くて model object 作ってせっせとマッピングしてるのがダルいというのが嬉しくないポイントなのだけど
— nash (@nashcft) February 23, 2022
JS/TS front-end だと GraphQL response も結局ただの JS object だから依存について気にする必要ないのだけど、 Android native は Kotlin (or Java) だから class として定義されてしまうので呼び側がそれが何かを知る必要が出てくる
— nash (@nashcft) February 23, 2022
Kotlin も structural subtyping 対応してくれ (そういう話ではない)
— nash (@nashcft) February 23, 2022
話題に出たことはあるらしい / https://t.co/KAnCkizTK1
— nash (@nashcft) February 23, 2022
GraphQL の error response は実質任意の構造の object って感じなので kotlin と相性悪いなって思った
— nash (@nashcft) February 23, 2022
Apollo Kotlin の Error まわりの実装:
Errorhttps://github.com/apollographql/apollo-kotlin/blob/7a1a291d5edc7d66d088c06b47975ef8a79fc439/apollo-api/src/commonMain/kotlin/com/apollographql/apollo3/api/Error.kt- パースしてインスタンスつくるところ https://github.com/apollographql/apollo-kotlin/blob/7a1a291d5edc7d66d088c06b47975ef8a79fc439/apollo-api/src/commonMain/kotlin/com/apollographql/apollo3/api/internal/ResponseParser.kt#L71-L102
GraphQL の error の format に関する仕様
