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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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.