Graphql As A Way To Serve...

## Why developers moved on from GraphQL to different solutions in 2024 ### GraphQL seems to be too complex for small projects My impression is that there's the general sentiment that GraphQL is too complex for small projects. Indeed, GraphQL adds complexity to your project, but this complexity also comes with some benefits. GraphQL forces you to have a Schema, either by defining it upfront (schema-first) or by deriving it from your code (code-first). But a Schema also gives you a lot of benefits, like being able to generate types for your frontend, and being able to generate documentation. It's worth noting that there's a lot of ongoing investment in making it easier to build GraphQL APIs. ... Now let's take a look at some considerations you have to make when rate limiting a GraphQL API. - You can rate limit based on the complexity of the query (depth, number of fields, etc.) - You can rate limit based on the number of Subgraph requests - You can rate limit based on the actual load on your origin server (but how do you measure that?) - How will a user know how much they can request? How can they estimate the cost of their query? - How can a client automatically back off when they're rate limited? … ### GraphQL creates a lot of security concerns GraphQL does indeed require you to think about security in a different way than REST. GraphQL inherits all security concerns from HTTP-based APIs like REST, and then adds some more on top of that because of the flexibility of the query language. As with rate limiting and caching, the GraphQL ecosystem is very mature and has solutions for security as well, but you can see that there's a theme here: A query-style API is fundamentally different from a URL-based API. The "Q" in GraphQL gives you a lot of power, and that comes at a cost. … ### Using GraphQL leads to unnecessary complexity I have empathy for this tweet. You use a technology that adds complexity to your project, and over time, it turns into a complete mess. We all have been there. What I've learned is that it's usually not the technology that's at fault, but the way we use it. You can mess up the architecture of a REST API just as much as you can mess up the architecture of a GraphQL API. When a team is incapable of building a good REST API, and then migrates to GraphQL, it'll surprise me if they suddenly build a good GraphQL API. … ### GraphQL makes projects slower, more complex, and more likely to fail This tweet carries a slightly negative sentiment, but we can take a look at the points made and see if they are valid. First, I think it's generally wrong to say that GraphQL makes projects slower, more complex, and more likely to fail. This is a very broad statement that's lacking specifics and is hard to prove. It goes on to say that 90% of GraphQL use cases can be handled by using a simple REST API. Why only 90%? There's almost no use case that you cannot model with REST. Lastly, it says that GraphQL is overused by engineers who prioritize their well-being over user value and time to market. I don't actually see this as criticism of GraphQL, but rather as criticism of engineers who prioritize their personal goals, e.g. using a technology they like, over the goals of the company. The last point is valid for any technology, not just GraphQL. We write software to solve problems for our users/customers (hopefully), not just to use the latest and greatest technology. That said, Engineers are also humans and want to enjoy their work. I think it's fine to use a technology that you enjoy as long as it doesn't hurt the company. … - GraphQL seems to be too complex for small projects - Rate limiting GraphQL APIs seems to be hard - Small teams don't benefit from the upsides of GraphQL - REST gets the job done - GraphQL doesn't play nice with the Web - GraphQL creates a lot of security concerns - You can just build a custom Endpoint for that - You don't need GraphQL when all use cases are known - Using GraphQL leads to unnecessary complexity - Server Actions, TypeScript and a Cache are all you need - GraphQL makes projects slower, more complex, and more likely to fail We can condense these reasons into one sentence: > GraphQL is too much overhead, and there are simpler alternatives like REST and RPC.