どうやらgraphQLのミューテーションは1つずつ順番に実行されるようです。
ソース ：
GraphQL では、ミューテーションはシーケンスとして実行されます。そうしないと、同じ作成者を何度も追加するなどのエラーを検出するのが難しくなります。
このようなミューテーションを実装するかどうかは、GraphQL サーバーの実装次第です。NodeJS 実装の参照と、Python および Scala の他のコミュニティ実装は、これに従います。
私がそれを正しく理解していれば、これは次のことを防ぎます:
この設計上の決定の背後にある理論的根拠は何ですか? それを別の方法で行う他のプロジェクトはありますか？
実際、GraphQL はリクエストの同時実行を強く推奨しています。リクエストは並行して処理できます。各リクエストは、そのリクエストの個々のミューテーションを順次実行しますが、複数のリクエストを同時に処理できます。
特に並行性に関して、ミューテーションとリクエストの違いを示すことが重要です。
GraphQL は、単一のリクエスト以外で編集がどのように適用されるかについて何も伝えないことを示すことも重要です。それはコードの抽象化です。SQL begin...commit を使用してデータベースの書き込みをブロックするか、直接更新呼び出しを行ってサイコロを振るかを決定します。
トランザクションの逐次編集処理は、データベース設計では非常に一般的な方法であり、このための一連のコマンドがほとんどのデータベース言語で見られます。
SQL では、多くの場合、ミューテーションは BEGIN と COMMIT で囲まれます。Redis では、MULTI EXEC ブロックがこの機能を提供します。
これは主に私が見たものです。ただし、順序付けされていない並列編集処理は、結果がパスに依存しないことを確認し、すべての ACID プロパティが保持されることを保証する方法を見つけることができる限り、確かに可能です。
多くの言語でこれを行う方法はありますが、Redis でのこれの実装例しか頭に浮かびません。
一連の短い Lua スクリプトに編集内容をマッピングして、シリアル化された自身のトランザクション キーの値をチェックし、一致が見つかった場合は、適用する前に戻ります。それ以外の場合は、編集を適用し、シリアル化された編集をトランザクション本文に追加します。
注: 依存する編集 (テーブルの作成、テーブルへのエントリのプッシュ) がある場合、シリアル編集の実行を回避することで、実際に自分自身を撃つことができます。
複数のリクエストにまたがるトランザクションに関しては？私はそれらを実際に使用したことはなく、このスレッドはその質問により適しています。