Are there any disadvantages to GraphQL?

问题:

All the articles about GraphQL will tell you how wonderful it is, but are there any disadvantages or shortcomings to it? Thank you.

回答1:

Disadvantages:

• You need to learn how to set up GraphQL. The ecosystem is still rapidly evolving so you have to keep up.
• You need to send the queries from the client, you can just send strings but if you want more comfort and caching you'll use a client library -> extra code in your client
• You need to define the schema beforehand => extra work before you get results
• You need to have a graphql endpoint on your server => new libraries that you don't know yet
• Graphql queries are more bytes than simply going to a REST endpoint
• The server needs to do more processing to parse the query and verify the parameters

But, those are more than countered by these:

• GraphQL is not that hard to learn
• The extra code is only a few KB
• By defining a schema, you will prevent much more work afterwards fixing bugs and enduring hairy upgrades
• There are a lot of people switching to GraphQL so there is a rich ecosystem developing, with excellent tooling
• When using persistent queries in production (replacing GraphQL queries with simply an ID and parameters), you actually send less bytes than with REST
• The extra processing for incoming queries is negligible
• Providing a clean decoupling of API and backend allows for much faster iteration on backend improvenments

回答2:

I have found some important concerns for anyone considering using GraphQL, and up until now the main points are:

Query In Indefinite Depth: GraphQL cannot query in indefinite depth, so if you have a tree and want to return a branch without knowing the depth, you’ll have to do some pagination.

Specific Response Structure: In GraphQL the response matches the shape of the query, so if you need to respond in a very specific structure, you'll have to add a transformation layer to reshape the response.

Cache at Network Level: Because of the commonly way GraphQL is used over HTTP (A POST in a single endpoint), cache at network level becomes hard. A way to solve it is to use Persisted Queries.

Handling File Upload: There is nothing about file upload in the GraphQL specification and mutations doesn’t accept files in the arguments. To solve it you can upload files using other kind of APIs (like REST) and pass the URL of the uploaded file to the GraphQL mutation, or inject the file in the execution context, so you’ll have the file inside the resolver functions.

Unpredictable Execution: The nature of GraphQL is that you can query combining whatever fields you want but, this flexibility is not for free. There are some concerns that are good to know like Performance and N+1 Queries.

Super Simple APIs: In case you have a service that exposes a really simple API, GraphQL will only add an extra complexity, so a simple REST API can be better.

回答3:

This biggest problem that I see with graphQL i.e if you are using with relational database is with joins.

1. The fact that you can allow/disallow a few fields makes joins non-trivial(not simple). Which leads to extra queries.

2. Also Nested queries in graphql leads to circular queries and can crash the server. Extra care has to be taken.

3. Rate limiting of calls becomes difficult coz now the user can fire multiple queries in one call.

TIP: Use facebook's dataloader to reduce the number of queries in case of javascript/node

回答4:

It's getting better and better each year, and as for now, the community of GraphQL is growing, and as a result, there are much more solutions to a lot of problems that were highlighted in other answers before. But to admit what is still holding companies from throwing all resources to GraphQL I'd like to list some issues and solutions followed by unsolved ones.

• Cache at Network Level - as Bruno said it's Persisted Queries and of course you can cache on a client and nobody stops you to use caching on database level or even Redis. But of course as GraphQL has only one endpoint and each query is different - it's much more complicated to do this type of caching than with REST.
• Nested queries in GraphQL leads to circular queries and can crash the server - not a problem anymore with a vast variety of solutions. Some of them are listed here
• Handling File Upload - we have already lots of solutions for it

But there are couple more cases which can be counted as disadvantages:

• boilerplate excessiveness ( by this I mean, for the creating for example new query you need to define schema, resolver and inside the resolver to explicitly say GraphQL how to resolve your data and fields inside, on the client side create query with exactly fields related to this data)
• error handling - I need to say that it's more related to comparison with REST. It's possible here with apollo but at the same time it's much more complicated than in REST
• authentication and authorization - but as I said community is increasing with outstanding speed and there are already couple of solutions for this goal.

To sum up, GraphQL is just a tool for specific goals and for sure it's not a silver bullet to all problems and of course not a replacement for REST.