HotChocolate GraphQL 服务器是否导致 API 和数据库之间的紧耦合?

Does HotChocolate GraphQL server lead to tight coupling between the API and the database?

我正试图围绕 GraphQL 进行总体研究,HotChocolate demo 我刚刚看过。以下是我认为的好处:

我的问题或顾虑(如果您愿意的话)是:这是否将我的 API 耦合到数据库的级别几乎肯定会在某个时候中断?如果我需要调整我的数据库模式,事情就会崩溃。这种担忧是否成立?

Hot Chocolate 或 GraphQL 通常只是作为现有 APIs 之上的一个小包装。

演示中显示为解析器的内容

[UseProjection]
// ...
public IQueryable<Entity> GetEntities(DbContext context) => context.Entities;

也可以是现有服务之上的一个小包装器,例如存储库。

public List<Entity> GetEntities([Service] IService service)
    => service.GetEntities();

链接演示中显示的数据中间件允许人们以尽可能少的样板和尽可能高效的方式开始,但它与 GraphQL 的本意存在内在冲突。

这最终是每个开发人员必须自己决定的权衡。有了 Hot Chocolate,数据中间件确实很强大,但它引入了耦合,也有其局限性。另一方面,您获得了快速(呃)移动、高效并避免通常需要的大部分样板的能力。

当然你也可以自由选择更传统的路线,有更多的样板,但解耦。在这种情况下,GraphQL 只是作为一个薄的 API 层,正如预期的那样。

我认为这就是 GraphQL 的美妙之处,您可以选择并能够在 GraphQL 服务器后面连接几乎任何数据源或服务。

关于您对数据库迁移破坏数据中间件的担忧。这是有效的,但大多数时候 Hot Chocolate 非常聪明,可以选择新字段并正确连接它们,而无需编写任何额外代码。

使用 HotChocolate,您可以选择以各种方式和方法进行设计,例如模式优先、代码优先或基于注释。

从架构的角度来看,您可以使用干净的架构并将您的应用程序很好地分层,然后在上面放一层薄薄的 GraphQL。

但是很多开发人员确实希望快速开发他们的数据库并直接公开它。

Hot Chocolate 可以让你做任何你想做的事情。 Hot Chocolate 核心实际上对数据库或 Entity Framework 一无所知。为了获得投影功能,您需要选择加入 HotChocolate.Data.* 包。

Hot Chocolate 不要求您的数据库或任何其他层之间有任何紧密耦合。