graphQL多重突变事务

Question

Apparently graphQL mutations are executed one by one sequentially.

Source :

• https://learngraphql.com/basics/invoking-mutations/4

In GraphQL, mutations are executed as a sequence. Otherwise, it's hard to detect errors like adding the same author again and again.

It's totally up to the GraphQL server implementation to implement mutations like this. Reference NodeJS implementation and other community implementations for Python and Scala follow this.

If I understand it right, this does this prevent :

• executing the requests in parallel
• the use of transactions over multiple requests

What is the rationale behind this design decision ? Are there other projects that do it differently ?

Answer 1

Actually, GraphQL highly encourages request concurrency. Requests can be handled in parallel. Each request performs the individual mutations of that request in serial, but multiple requests can be processed concurrently.

It's important to denote the difference between mutations and requests, especially regarding concurrency.

It's also important to denote that GraphQL tells you nothing about how the edits are applied outside of a single request. It's your code abstraction, you decide whether to use SQL begin...commit to block database writes or just make the update calls directly and roll the dice.

Serial edit processing on a transaction is a very common practice in database design, and a set of commands for this can be seen in most database languages.

In SQL, mutations are often bracketed by BEGIN and COMMIT. In Redis a MULTI EXEC block offers this functionality.

This is primarily what I've seen. However, unordered, parallel edit processing certainly is possible as long as you make sure the results are path independent and you can find a way to guarantee all ACID properties hold.

There are ways to do this in many languages, but I can only think of an example implementation of this in Redis off the top of my head.

You could map the edits to a set of short Lua scripts that check the value of the transaction key for their serialized selves, and if they found a match, they'd return before applying. Otherwise, they'd apply the edit, and append the serialized edit to the transaction body.

NOTE: If you have dependent edits (Create table, push entry to table), you can really shoot yourself in the foot avoiding serial edit execution.

As far as transactions over multiple requests? I've never really used them and this thread is more suited for that question.

Multi-step database transaction split across multiple HTTP requests