为什么GraphQL没有成为主流

GraphQL是一种用于API的查询语言，由Facebook在2012年开发并在2015年开源。它提供了一种更有效和更强大的数据获取方式，相比于传统的RESTful API，它有以下几个主要优点：

• 数据获取效率高： 客户端可以精确地获取它需要的数据，而不需要获取额外的、不必要的数据。这可以减少数据传输量，特别是对于移动设备来说非常有用。
• 单次请求获取多个资源： 在RESTful API中，获取多个相关资源通常需要多次请求。而在GraphQL中，客户端可以在单次请求中获取多个资源。
• 类型系统： GraphQL有一个强大的类型系统，可以让你在API中定义复杂的、嵌套的数据结构。这可以帮助你编写更健壮的API，并提供更好的开发者体验。
• 实时数据： GraphQL支持订阅，这意味着客户端可以订阅某些数据的变化，当这些数据变化时，服务器会将更新的数据推送给客户端。

在GraphQL中，客户端发送一个包含查询或变更的请求到服务器。查询用于获取数据，变更用于修改数据。服务器解析请求，执行相应的操作，并返回一个响应，响应中包含请求的数据和可能的错误信息。

以下是一个GraphQL查询的例子：

query {
  user(id: 1) {
    name
    email
    friends {
      name
    }
  }
}

这个查询会获取id为1的用户的名字、电子邮件以及他的所有朋友的名字。

作为一种API设计范式，GraphQL 刚出场时还是很惊艳的，曾经以后可以替代RESTful API，然而实际使用后，发现还是存在不少问题的，这可能也是其在国内没有成为主流的原因吧。

我经过实际体验，主要问题如下：

• 学习曲线：

对于新手来说，GraphQL的学习曲线可能会比较陡峭。特别是对于那些习惯了RESTful API的开发者来说，他们需要理解一种全新的查询语言和一种不同的思考方式。

可以总结一下，三年不用RESTful API你还是可以使用，但三个月不用GraphQL，你可能会忘记GraphQL查询语法。

• 性能问题

由于GraphQL允许客户端进行深度嵌套的查询，这可能会导致一些性能问题。例如，一个恶意的客户端可能会发送一个非常深度的查询，导致服务器资源耗尽。
为解决性能问题，必然得引入缓存机制，由于客户端可以自由地组合查询，这使得缓存策略变得很复杂。

• 负载均衡

在RelstFul中，我们很容易根据URL结合Nginx来进行API负载均衡，但是GraphQL只有一个访问端点，也就是只有一个URL，这使用做负载均衡比较困难，需要更多的复杂机制。

• 访问控制

在RelstFul中，我们很容易为每个API Controller进行访问控制，但是在GraphQL，一个访问端口+一系列复杂的Resolver树，访问控制变得很复杂。

• 版本管理

在RESTful API中，我们可以通过URL路径来管理不同版本的API，而在GraphQL中，由于只有一个端点，版本管理变得更加困难。

当然，所有问题事实上均有对应的的解决方案，在国外，GraphQL已经形成了庞大的生态，每个问题均有相应的解决方案，但是总体而言，RelstFul更加简单，我想这更加重要吧。