I want to pose a question that has been bothering me for quite some time.
A project I am working on has decided (some time ago) to use a UI written in React that communicates with the backend ONLY using GraphQL query/mutations (with all the various Redux, RTK, etc).
Now, as long as it’s primarily about fetching data, I don’t have major complaints.
The problem is that GraphQL Mutations are used for ANYTHING that doesn’t fall under a query.
To give you some examples:
- Need to send an email? => Call a Mutation (which will reply, say, OK or KO, or an error)
- Complex contract that needs to be validated before proceeding? => Call a Mutation that validates the contract and tells me OK or KO.
Now, this smells a lot like technology abuse to me (like: GraphQL is the latest trend -> we use it for everything).
Plus, writing a Mutation is much more complex than writing a simple POST endpoint, both on C# and React side…
My questions are:
- have you ever encountered something like this?
- what do you suggest I do?
1 Answer
We had the same issue when implementing graphql. And I think we had it because we wanted to use the same principles as REST on our mutations. Which ended up bad, with a lot over overhead on our backing services.
We then tried to see graphql as a "frontend" instead. Anything you (can) do on the frontend will have functional query or mutation on graphql. We ended up with less frustration. Our mutations were called by the interaction, instead of the resource we were trying to manipulate. For example addProductToCart instead of postCart. Or addCouponToCart instead of putCartCoupon. writeProductReview instead of postReview, etc. The backend either has their own set of mutations, or sometimes we used REST instead.
We also had attached this to our microservices, and used a lot of graphql federation (for microservices which had a graphql endpoint) and backend stitching.
I have to say we had to quit the project due to other reasons than the technology, but it’s easy to fall into the REST mindset when using graphql.
I’m not sure if this is what you were looking for, but that’s a bit of our journey of using graphql.
