That's just as easy to do in a REST API with something like Django REST framework Serializers. Those can be nested arbitrary, and when you're adding a field to one serializer you have no way of knowing all the places where that field might appear deeply nested from some other serializer (without just manually checking all of your serializers). Of course, you can prevent this problem with stronger conventions or tools, but in my experience those conventions and tooling are no better for REST APIs than they are for GraphQL.
Good point! Maybe the better argument is that it might be easier to secure a REST API since there are more resources, best practices, and more engineers with experience. With GraphQL, there's just so many new things to worry about as well (i.e. hiding parts of the graph from the public).
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 just as easy to do in a REST API with something like Django REST framework Serializers. Those can be nested arbitrary, and when you're adding a field to one serializer you have no way of knowing all the places where that field might appear deeply nested from some other serializer (without just manually checking all of your serializers). Of course, you can prevent this problem with stronger conventions or tools, but in my experience those conventions and tooling are no better for REST APIs than they are for GraphQL.
Good point! Maybe the better argument is that it might be easier to secure a REST API since there are more resources, best practices, and more engineers with experience. With GraphQL, there's just so many new things to worry about as well (i.e. hiding parts of the graph from the public).