丁哥看软件（三）：不做技术的奴隶

这个话题借API技术来展开说一下，我有如下的理解跟大家分享一下: 技术是工具, 是为人服务的。而不是反过来。我们不能说为了迎合某种技术而束手束脚，让我们自己特别难受。

你比如说rest的理念，就是提供简单的对单一资源的crud请求操作。而实际的业务场景中，我们需要用到多种资源，而不是单一资源，这样子如果严格的按照rest的理念来教条式的应用，必然就会导致请求效率和计算效率的低下。

那么自然而然的，我们就想我一个请求是不是可以定义一个model，然后这个model包含我需要的多种资源数据。

这里的model的要区别于rest中使用的entity, entity是对应具体资源表格的, model是对应多个资源表格的某些字段的。

我们知道这样的一个请求，在rest中对应着一个路径，若干参数，一个负载payload。在服务器后端处理这个请求的时候，它会对应一个处理函数。

在这个处理函数中，我们可能涉及到多个表格，多个数据源的计算操作。那么通过这样的设计，我们就避免了在前端进行多次的请求，而改成通过一个请求就完成了对于多个数据资源的获取。这样就可以提高整个业务请求的处理速度。

上面这个过程是采用了graphql的理念，使用了rest的技术。

graphql作为一个理念本身没有指定具体的技术,那么这里就有一个问题: 我们应该选择什么样的技术来践行这个理念。

上面我提到的是一种，我认为这种是目前最好的选择。

以appello为代表的SDK为graphql的理念践行了很多有意义的工作。

让程序员感到比较兴奋的是对前端工作的简化。这部分工作的具体实施跟我上面提到的用model来代替entity的模式是一样的，异曲同工。

但是后端这一块儿, 使用graphql的复杂度增加了, 在rest中一个handler function可以做的事情, 在graphql中需要endpoint class, schema, resolver, parser等等。不仅仅是编码的复杂度，程设计的复杂度也提高了。相比，rest中直接调用repository或者service处理逻辑, graphql需要绕一圈以后再去调用repository或者service进行处理,执行效率也相比rest下降了。

gRPC使用二进制数据作为传输媒介，相比graphql和rest，传输效率更高了。定义proto文件以后，使用编译工具生成客户端和服务器端代码的方式提高了编码效率。

通过函数调用的方式来实现网络请求也简化了代码的编写。

但是它的一个问题是不支持HTTP1.0和1.1。这意味着网页程序无法使用gRPC的API。