pleroma.tenjuu.net

GraphQLって mutation いる？なんかクエリ言語で mutation みたいな操作がでてくるとやりづらさを感じる

たとえば article の公開という操作があるとき、rest であれば `publish` という意味付けられた操作を定義して、 /article/{id}/publish みたいなエンポイントに引数なしで put するけど(非公開の場合は close とか unpublish とか)、GraphQLでは article の mutation に published フラグを true で渡すとか、そういうのをよくみる気がする(いやこれはrest でもやる人はいるけど)。ただ、`articlePublish` という mutation をつくって article の id を渡す、とすれば上記と似ているけど、GraphQL ではほぼ article id をURLに埋めこむことができなくて、それは決定的に REST とは違う。

mutation が結局「データを操作する」になりがちで、それに直接対応したUIを想定すると、脳内でデータの意味を構築して操作の手順を組み合わせる必要があるようなUIになる。それで、では mutation の基本的な構造とUIは別だということになるのであれば、プログラマの立場からはUIとデータモデルを別な仕様として定義する必要があることになり、不当に仕事量が多く見える。
自分の感じていることとしては、GraphQLは操作の単位で切りだすことが困難だということ(できないわけではない)。

UIを作るのって結果的にはつねに操作を定義することになるけど、GraphQLがもたらしたのって操作とデータの分離で、このギャップをどこかで埋める必要がでてくるわけだが、そのギャップをユーザーにおしつけるか、プログラマーが頑張ってデータと意味の変換層をつくるか

クエリ言語はクエリ言語でいいんだけど、クエリ言語で更新系を処理しようとするの一般的にアンチパターンになる、とかそういうのないですか？

やっぱりフロントからみるとGraphQLってどうしてもデータベースになってしまうわけで、操作の体系的な意味もフロント側にあることになるけど、そうするとバリデーションとかみんなどうしてんの？サーバーサイドでコントロールしないと厳しくない？

デザインにせよプログラムにせよ、課題はつねに秩序が形成できるかどうかであって、RESTはこの秩序を形成するための規約だけど、GraphQLにはそういうものがない。RESTを前提にした場合にはいくつか有益なパターンが明確にあり、Rails などはあきらかにそれを取り入れている。

管理画面で頻出するパターンなんかはとくに rails/rest 向きで、graphql は向かないと感じる。ユースケースの多くがそれぞれ固有の制約を抱えており、ユースケース固有の遷移・意味・操作などがあるけど、そういうのは graphql でみんなどうしてるんだろ。