如何在GraphQL Apollo客户端中处理异步突变

Question

Structure

This is a question how to best use Apollo Client 2 in our current infrastructure. We have one Graphql server (Apollo server 2) which connects to multiple other endpoints. Mutations are send via RabbitMQ and our Graphql also listens to RabbitMQ which then are pushed to the client via subscriptions.

Implementation

We have a Apollo server which we send mutations, these always give a null because they are async. Results will be send back via a subscription. I have currently implemented it like this.

• Send mutation.
• Create a optimisticResponse .
• Update the state optimistically via writeQuery in the update function.
• When the real response comes (which is null) use the optimisticResponse again in the update method.
• Wait for the subscription to come back with the response.
• Then refresh the the state/component with the actual data.

As you can see.. not the most ideal way, and a lot of complexity in the client.

Would love to keep the client as dumb as possible and reduce complexity. Seems Apollo is mostly designed for sync mutations (which is logical).

What are your thoughts on a better way to implement this?

Answer 1

Mutations can be asynchronous

Mutations are generally not synchronous in Apollo Client. The client can wait for a mutation result as long as it needs to. You might not want your GraphQL service to keep the HTTP connection open for that duration and this seems to be the problem you are dealing with here. Your approach responding to mutations goes against how GraphQL is designed to work and that starts to create complexity that - in my opinion - you don't want to have.

Solve the problem on the implementation level - not API level

My idea to make this work better is the following: Follow the GraphQL spec and dogmatic approach. Let mutations return mutation results. This will create an API that any developer is familiar working with. Instead treat the delivery of these results as the actual problem you want to solve. GraphQL does not specify the transport protocol of the client server communication. If you have websockets running between server and client already throw away HTTP and completely operate on the socket level.

Leverage Apollo Client's flexible link system

This is where Apollo Client 2 comes in. Apollo Client 2 lets you write your own network links that handle client server communication. If you solve the communication on the link level, developers can use the client as they are used to without any knowledge of the network communication details.

I hope this helps and you still have the chance to go in this direction. I know that this might require changes on the server side but could be totally worth it when your application is frontend heavy (as most applications are these days)