GraphQL Cons

What REST limitations does GraphQL attempt to overcome ?

• It emerged in 2012 during social media boom
• 1) fixed structure data exchange : fixed structures 
• 2) over fetching vs under fetching : REST API always return whole data set.

After few years of using GraphQL in production people in the community aren't reaching for it as much as we once did. 

• First up, security. GraphQL's self-documenting query API increases attack surface. Every field needs careful authorization based on context, a far bigger task than securing REST endpoints.
• Performance is another challenge. GraphQL's flexibility allows crafting queries that can consume significant server resources. Rate limiting becomes more complex compared to REST, requiring estimating query complexity.
• Parsing invalid GraphQL queries can lead to memory issues due to error response generation, requiring additional mitigations not needed in REST.
• GraphQL's nested queries often lead to N+1 problems in both data fetching and authorization. The Dataloader pattern helps but introduces boilerplate and complexity.
• Solving GraphQL's performance and security issues often couples business logic with the transport layer, making testing and debugging more challenging compared to REST.
• For many use cases, an OpenAPI 3.0+ compliant JSON REST API might be a better fit. It provides type safety and self-documentation without GraphQL's complexity.
• Emerging tools like TypeSpec offer promising "specification first" approaches for generating type-safe APIs, similar to GraphQL's "schema first" approach but for REST.

While GraphQL has its strengths, its complexity can be overkill for many projects. As always, choose the right tool for the job.

https://aws.amazon.com/compare/the-difference-between-graphql-and-rest/

When to use GraphQL vs. REST

You can use GraphQL and REST APIs interchangeably. However, there are some use cases where one or the other is a better fit.

For example, GraphQL is likely a better choice if you have these considerations:

• · You have limited bandwidth, and you want to minimize the number of requests and responses
• ·       You have multiple data sources, and you want to combine them at one endpoint
• ·       You have client requests that vary significantly, and you expect very different responses

 

On the other hand, REST is is likely a better choice if you have these considerations:

• ·       You have smaller applications with less complex data
• ·       You have data and operations that all clients use similarly
• ·       You have no requirements for complex data querying