The Good

• The schema is almost complete documentation in itself, which is often neglected on REST API development.

• Instead of POST /posts you can call createPost, know exactly the expected input and response. This makes it more intuitive for frontend developers to just consume your API. It makes it easy to simply call the function you need from your service instead of forcing yourself to use a pattern like REST or HATEOAS.

• If you are building a REST API something like Swagger or with a paid Postman plan that allows more than 5 collaborators it's another extra thing to keep in mind.

The Bad

• The Apollo Server has changed or dropped support for features like Schemas directives and subscriptions, so you might need to update your code more than a simple Express app.

• GraphQL can make things like caching more tricky and you need some extra work to configure persisted queries.

• You better setup something like graphql-query-complexity to avoid queries complex enough to crash your server or database.

The Ugly

• If you don't want to return specific fields it's better to only query the fields you need in the first place instead of completely relying on GraphQL as a DTO. Something like graphql-fields is useful in this case. On a REST API you can simply create a fields or excludeFields param that makes it easier for the client to select or ignore fields it does not need. In some Google APIs this is the part param.

• It's easy to both underuse or overuse fragments and either keep fetching data you don't need on your client anyway or making it too complex with too many different fragment configurations.

• If you are using TypeScript, you need to both specify the input in your typeDefs and create a equivalent typings for your resolvers, repeat yourself and make sure those match.

• GraphQL will check for the correct types but you will still need input validation from another library, forcing you to define your input once again, or a couple of custom directives.