DEV Community

Discussion on: Why we are moving off REST and implementing GraphQL

Collapse
sirseanofloxley profile image
Sean Allin Newell

I don't fully understand how GraphQL mutations alleviates any of the concerns outlined with PATCH endpoints, could you explain that a bit further? I'm interested in graphql and am about to dive neck deep into it, but have concerns about how to live long term with graphql while requiring relational data in MySql for example

Collapse
jwhenry3 profile image
Justin Henry

The issue with PATCH is that there is no official RFC that states exactly how a PATCH should be performed, but there are sources that recommend one pattern over another, like a transaction-pool. I assume where the PATCH alleviation comes in is that GraphQL provides a uniform way to perform partial updates, which takes some of the burden of implementing custom PATCH endpoints off of your shoulders.

Collapse
sirseanofloxley profile image
Sean Allin Newell

That's kinda weak imo; but if you find value in that and it works for your products n projects, great! More power to ya! I'd love future posts comparing some common product focused use cases between graphql and rest, that'd help me grok it more.

<3<3

Thread Thread
jwhenry3 profile image
Justin Henry

I don't use GraphQL personally or in a professional capacity, so I can merely speculate as you are, but ultimately I have had semantical debates with others on the proper way to patch, so in some ecosystems having conflicts like that removed makes sense. I agree that it's not enough to convince me to change. What can, however, is if it dynamically includes only the requested properties and relationships based on the data model requested in the request, which I think it does. If you care about your payload sizes and mitigating data load on mobile devices, I can see where GraphQL would excel in that regard.

I agree that seeing use cases makes the persuasion that much more convincing.