Are there any disadvantages to GraphQL? [closed]

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

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.

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

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.

It’s really great to have a single endpoint and expose all the data. I find below points to be considered for GraphQL:

1. Implementation of File Download / Upload gets tricky (converting to string might not be a best option for large files)
2. A lot of boilerplate and schema code at both frontend and backend.
3. Follow and support pagination provided in the GraphQL specification.
4. Allow custom order and prioritizing logic for ordering of fields. Example if we fetch users data and associated groups and roles. A user can multi sort the data based on username, group name or role name.
5. Authentication and Authorization would be dependent on the backend framework.
6. Ensure the backend optimization and Database support to fire single query for each graphql command might get tricky.

Also, one should consider the Pros after its implementation :

1. Very flexible to support new items and update existing behaviour.
2. Easy to add conditions using arguments and custom ordering once implemented
3. Use a lot of custom filters and get rid of all the actions that needs to be created example a user can have id, name, etc as arguments and perform the filtering. Additionally the filters can be applied on the groups in the users as well.
4. Ease of testing API by creating files containing all the GraphQL queries and mutations.
5. Mutations are straightforward and easy to implement once understood the concept.
6. Powerful way to fetch multiple depths of data.
7. Support of Voyager and GraphiQL UI or Playground makes it easy to view and use.
8. Ease of documentation while defining the schema with valid description methods.

I think graphql for the moment must be part of the backend architecture, for file upload you still hit a regular api