GraphQL はちょっとイライラする
(news.ycombinator.com)- GraphQL は素晴らしいが、少し持ち上げられすぎている気がする
- 初級〜中級の開発者は YouTube を見て GraphQL を使うようになることが多いようだが、これは間違っている気がする
- 長所
- 欲しいデータを簡単に記述できる
- 帯域幅を節約できる。必要な分だけを一度に取得できる
- データ利用者向けのドキュメントを作りやすい
- サブスクリプションをより簡単に使える
- API 呼び出しをまとめることができる
- 短所
- 実際に使うのはつらい。使っているバックエンドに応じてあなたの言語向けに生成してくれないなら、2 つ以上の型システムを管理しなければならない
- マップ/テーブル/ディクショナリをサポートしていない。これは本当に大きい。やりたくはないが、どこかでは
{[key: string] : T}を使うことになる - API のバージョン管理について明確な方法がない。結局は
MyQueryV1.01MyQueryV1.02MyQueryV1.03のようになってしまう
- Facebook が GraphQL のために想定した解決策/問題セットをあなたが扱っているのでなければ、GraphQL を使わないでください
- 他のシニア開発者たちは、どんな賢い言葉で新人開発者がこの泥沼にはまるのを救えるでしょうか？
HN のコメント
- GraphQL の最大の問題は、DoS 攻撃を防いだり、データベース全体をダウンロードしようとする人たちを止めたりするための対策が必要なことだ。
- システムに過剰な負荷をかけるクエリを作るのが非常に簡単だ。
- 何をしなければならないかを見るなら Shopify を見ればよい。返されるデータ量に対してレートリミットをかけ、カーソルとページネーションにも対応している。インターネットで見かけるきれいな GraphQL の例とは違って、スキーマは巨大で見た目もよくない
- GraphQL は、大手テック企業が抱える組織上の問題を解決する優れた方法だ
- たとえば API を保守するチームと変更を要求するチームが別である場合
- 組織が大きいとこのような場合に変更を待つのに非常に時間がかかるので、GraphQL はその必要を減らしてくれる
- 小さな組織なら、足りない部分を自分たちで作ってしまえばいいのではないか？
- 意図されたものかどうかは別として、GraphQL はフロントエンド開発者がバックエンド開発者への依存から切り離され、より速く動けるようにしてくれる
- バックエンド開発者がデータモデルを作って GraphQL として公開すれば、そのバックエンド開発者に一度も会ったことがないフロントエンド開発者でもすぐに使える
- その場でクエリ内容を変更して、欲しいものを得られる
- みんなが速く動けるようになる
- しかしバックエンド開発者である私は GraphQL が本当に嫌いだ
12件のコメント
GraphQL はちょっとイラッとしますよね。ものすごくイラッとするほどではないですが、少しはイラッとします。でも、チーム内のコミュニケーションコストを確実に下げてくれるので、その時間でイラッとする部分を解決するほうが効率的です。そして見た目は本当に不格好です。ですが私は GraphQL を使うことを勧めます。だって、tRPC を使おうという意見に誰も賛成しないでしょうから。たいていの人は、ちゃんと使ってみたこともないのに先入観で技術導入を拒みますし、それを解決しようとすると強い権限で押し切るしかないのですが、1〜2 個の技術ならそれもできても、何もかも押し通すと失うもののほうが多くて無理です。……だから結局、できるだけ説得可能なラインが GraphQL なんです。クソみたいな REST、これこそ本当にコミュニケーションコストがものすごくかかる悪しき旧石器時代の技術です。
GeekNewsを見ていて、会員登録したくなる文章は初めてですね。The bad パートに返信してみました。
クライアント/サーバーそれぞれの視点で見た長所短所はあるでしょうが、まとめて見たときにサーバーとクライアントの間に欠けていた抽象化レイヤーを GraphQL スキーマが埋めてくれる、という最大の value proposition を分かっていながら、一般的なプロダクトで REST を検討するという話は、個人的には少し古い話のように聞こえます。
The bad
two or more type systems if there are no code first generates in your language
結局、言い換えれば、ちゃんと使えば良いということですよね？ code generation みたいな話は、今どき問題でもないでしょう。ツール群がどれだけ進化したと思っているんですか。
some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
Production Ready にも言及されている内容ですが、Type System の長所を活かせば、そこまで悩む必要はない部分だと思いますね。key: string ではなく、正確なフィールドを指定すれば済む話で……
そもそも GraphQL はバージョンレスです……。
Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
React も Facebook が解決しようとしている問題を解くのでなければ使うな、と言っているように聞こえますね。
こんにちは、よいご意見ですね。もしよければ知り合いになりませんか。こういう考えの方が必要です。ほかの人（チームメンバー）を説得するのが本当に大変です。
www コメントを見るのが遅くなりました…!! 私は GraphQL Korea の Slack で Alucard というニックネームを使っています :)
GraphQLは比較的早い段階で導入したのですが、当時はバックエンド寄りの説明が多くありました。そうなると、バックエンドにとって何か良いもののように認識されているのではないかと思います。
私があれこれ試行錯誤してみた末に、その後会社に入ってきた方や面接を受ける方に質問されたときは、バックエンドにとっては大変だけれど、フロントエンドにとっては良いものだと説明しています。 :)
でもバックエンド開発者の私はGraphQLが本当に嫌い
共感します..
まさに適材適所という言葉が思い浮かびますね。
これが GraphQL を使う理由です。GraphQL の仕様にも、フロントエンドのためのものだと明記されています 1
私も新しいスタートアップで GraphQL を使い始めましたが、以前より API についてフロントエンドエンジニアとやり取りしなければならない回数が確実に減ったように思います。
GraphQL を実際に使う前には思いもしなかった問題が、バックエンドエンジニアの立場では少しつらいこともありますが、REST API の設計をうまくやろうと頭を抱えるよりは、ずっと良いと思います。
どんな技術も完璧ではありませんよね！ 私は、その技術が必要だったり、別のより大きな問題を解決してくれたりして、欠点を解消するためのコストを受け入れられるなら、導入を検討する価値はあると思います。技術やツールの適性は、常に使う側の状況によって決まるものですからね。
一方で、GraphQLが批判される理由の一つは、「簡単だ」というイメージをアピールしてきたからではないか、という気もしますね。
GraphQLが出始めた頃にPOCプロジェクトを進めていたとき、multipartをきちんとサポートするエンジンがなくて、大変だった記憶がありますね..
私も以前から小規模プロジェクトでGraphQLを使ったという話を見るたびに、これはさすがにオーバースペックじゃないか……とよく思っていましたが、みんな考えることは似ていますね。
冒頭のコメントだけ訳してみました。400件を超えるコメントが付いていて、全部読むのも大変ですね。