GraphQL：多くの小さな突然変異、または1つのバルク突然変異？

Question

私はユーザーで、任意のアプリで自分のプロフィールを編集しています。アプリケーションは私に変更の束を作りましょう、そして、私が完了したら、私は "保存"をクリックし、私のプロフィールは更新されます。

このような大きなアップデートを処理するために、GraphQLで推奨されるベストプラクティスは何ですか？私が見る通り、いくつかの選択肢があります：

A）多くの小さな突然変異。ユーザーが5つのアイテム（名前、メール、ユーザー名、画像、生体）を変更した場合、クライアントはサーバーに対して5つの突然変異を発生させる可能性があります。

長所：小さく、より独立した操作。

短所：これは、GraphQLの「1回のラウンドトリップ」の目的を敗北させるものではありません... 5？

B）多くの小さな突然変異は、サーバー側と呼ばれています。 5回のラウンドトリップを必要とするクライアントから5つの突然変異を呼び出すのではなく、データブロブをサーバーに送信し、それを解析し、見つかったデータに対して個々の突然変異を実行する機能を持つことができます。

長所：1つの往復

短所：私たちは、これを処理するアプリケーションに別の層を追加する必要があります。新しい機能は厄介になり、テストが難しくなり、時間の経過とともに維持しにくくなります。

c）大きな突然変異の1つ。ユーザーは、単一の突然変異によってサーバーにデータBLOBを送信します。単一の突然変異を使用すると、各フィールドで個々の突然変異を実行するのではなく、文書の新しいデータをまとめて設定します。

長所：DX; 1ラウンドトリップ。

短所：フィールドが引数として渡されているため、攻撃するアプリケーションが開きます。悪意のあるユーザーは、変更すべきではないフィールド（すなわち、isAdminフィールド）を設定するなど、任意のフィールドを渡すことができます。どのフィールドが更新されるかを知るには突然変異が賢明でなければなりません。 。

---

GraphQLでこのようなことを行う「正しい方法」は、どのような方法でWeb上にあるのでしょうか。ここでいくつかの答え/フィードバックを見つけることを願っています。ありがとう！

Answer 1

私は第3の解決策大きな突然変異と一緒に行くつもりです。私は、悪意のあるユーザーが任意のフィールドを渡すことについてのあなたの点を理解していません。自分のスキーマで定義されていないフィールドを渡すことはできません。

サーバー側のロジックに関しては、とにかくこれらのスマートチェックを置く必要があります。クライアントを信用することは決してできません！