But one of the things that makes GraphQL complicated is having to specify the fields you want returned, and having to write out your object structure as a string all over your code.
I agree that gql makes the API contract more explicit, but it doesn't make it any harder to break. Whether your 3rd party API provider makes a breaking change to their REST or gql API, either way your client code is still broken.
You don't have to agree with your team on when to use which HTTP method, query-string, or paths, how to structure the URL, how to specify additional parameters like the limit of results and fields to return
Any REST API should follow the REST conventions for naming, routes, verbs etc. Nothing forces you to follow them, but, nothing forces a GQL mutation to actually mutate anything. Nothing stops you making db changes during a query.
Not to mention:
more difficult to set up API output caching when there's no simple GET /entity/id urls, but instead a gql blob that could be structured differently for every single use case
not well suited to typed languages eg C# & typescript, where you'd prefer to use classes and swagger/openapi to generate the contract. Using gql with typescript means repeating every type as both a typescript interface, and in the gql query string, which will be prone to typos etc. Yes, it is possible to generate ts classes from a gql spec, but that defeats the ability to specify only certain fields from a response.
By the way, an alternative REST API that optionally lets you specify the returned fields, as well as filtering, is OData. In that case, your REST URL would be eg /launches?$top=2&$select=mission_name,launch_date_local&$expand=rocket
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.
But one of the things that makes GraphQL complicated is having to specify the fields you want returned, and having to write out your object structure as a string all over your code.
I agree that gql makes the API contract more explicit, but it doesn't make it any harder to break. Whether your 3rd party API provider makes a breaking change to their REST or gql API, either way your client code is still broken.
Any REST API should follow the REST conventions for naming, routes, verbs etc. Nothing forces you to follow them, but, nothing forces a GQL
mutationto actually mutate anything. Nothing stops you making db changes during aquery.Not to mention:
By the way, an alternative REST API that optionally lets you specify the returned fields, as well as filtering, is OData. In that case, your REST URL would be eg
/launches?$top=2&$select=mission_name,launch_date_local&$expand=rocket