应该引入基于GraphQL + MongoDB的API服务器作为DApps的后端的原因

DApps是指非中央集權型應用程式或分散式應用程式，但實際上，這些應用程式其實是中央集權型應用程式”CApps”，這一點已為人所熟知。考慮到應用程式的樂趣和用戶友好性，我認為在一定程度上變成中央集權型是無可避免的。

在追求DApps用户体验的改进时，我们考虑采用哪种架构。核心是GraphQL + MongoDB的API服务器。

为什么选择API服务器？

作为合约的一个不擅长之处，其中之一是获取列表数据。
要获取合约内的列表数据，需要循环数据数量并发出事务，而且如果要在合约内实现搜索功能，则需要增加大量代码并使代码变得混乱，因此很难提供丰富的搜索功能。
因此，为了提高用户体验，需要将合约数据与数据库同步，并通过API获取数据的后端。
此外，如果多个服务引用相同的合约，则需要在所有服务中共享ABI和合约地址，但通过将ABI和合约地址保存在数据库中，还可以通过API服务器自由获取ABI和合约地址。

构成图

为什么要使用GraphQL。

基本上，在DApps中，前端是主角。(尽管在后端进行交易代理发行的服务是另外一回事。)由于DApps的前端具有持有私钥的属性，所以前端往往要承担包括交易发行在内的所有业务逻辑。为了明确分离责任，在业务逻辑方面应由前端处理，而API则只需返回数据。

如果使用GraphQL，前端可以使用查询来指定所需的项目并获取数据，因此不需要在服务器端进行除了返回数据之外的逻辑。
此外，数据的更新在合同端进行，因此API服务器只需要引用功能，所以不需要在服务器端实现认证、验证等逻辑。
因此，使用GraphQL可以通过一个端点提供高度自由的引用功能，从而极大地减少了应在服务器端实现的逻辑，使其非常简单且易于理解的配置。

基于这些原因，我认为在DApps的API服务器中应该使用GraphQL。

为什么要使用MongoDB

严格来说，并没有特定必须选择MongoDB的理由，但是合同内的数据并不存在关联性，并且需要监视合同事件并快速存储数据，从性能角度而言，NoSQL比关系型数据库更适合。此外，为了实现更丰富的搜索功能，我们认为应该选择能够发出相对自由度较高查询的MongoDB。

结尾处

现状DApps中尚无明确的事实标准，因此可能还有其他好的方法，但我认为采用GraphQL + MongoDB构建API服务器的方法非常方便。
此外，未来可能会出现解决方案，通过智能合约实现所有功能，因此DApps的进化令人关注。

我在博客上也写过这篇文章。
为什么应该在DApps的后端使用GraphQL + MongoDB的API服务器。