从架构设计视角：微服务/Step Function应直连MongoDB还是走GraphQL API？

一、微服务：直接查询数据库还是通过GraphQL API？ #

核心看数据访问的范围和耦合性：

• 直接查询数据库：
  • 优势：少一层网络调用，性能更高；微服务内部逻辑闭环，无需依赖外部API服务。
  • 劣势：耦合数据库Schema，一旦Schema变更可能影响服务逻辑；跨微服务查询时，需要调用多个服务的API，前端或上层服务要做数据聚合。
• 通过GraphQL API：
  • 优势：前端/上层服务可按需获取数据，减少冗余请求；统一API入口，解耦微服务与客户端；跨服务数据聚合由GraphQL层处理，简化上层逻辑。
  • 劣势：多了一层GraphQL网关的开销，需要额外维护网关的Schema和 resolver；如果只是单服务内部查询，会增加不必要的复杂度。

实际架构中常见方案：微服务内部直接操作自身数据库（保持服务独立性），跨服务查询、前端数据请求统一通过GraphQL网关处理（兼顾灵活性和解耦）。

二、Step Function场景：直接查询MongoDB还是调用GraphQL API？ #

Step Function作为流程编排工具，选择依据是流程的数据依赖范围：

• 直接查询MongoDB：
  • 适合场景：流程仅涉及单一微服务的数据，或需要高性能的单数据源读写。比如流程中仅需读取本服务的MongoDB数据做业务判断，直接查询更高效，避免额外API调用开销。
• 调用GraphQL API：
  • 适合场景：流程需要聚合多个微服务的数据，或复用已有的GraphQL查询逻辑。比如流程中需要获取用户、订单、支付三个服务的数据，通过GraphQL一次聚合比调用三个REST API更简洁，也避免Step Function直接连接多个数据库带来的耦合。

常见方案：如果Step Function是跨服务的流程编排，优先调用GraphQL API来统一获取数据；如果是单服务内部的流程，直接操作数据库更合适。

三、GraphQL的核心适用场景 #

• 前端灵活取数需求：移动端、Web端等不同客户端需要不同字段组合，GraphQL允许客户端按需请求，避免多次REST请求或冗余数据传输。
• 跨服务数据聚合：替代多个REST接口的组合调用，通过GraphQL网关一次获取来自多个微服务的聚合数据，简化上层服务或客户端的逻辑。
• API平滑演进：无需发布新的API版本，新增字段不会影响旧客户端（旧客户端可以忽略新增字段），降低API维护成本。
• 实时数据场景：结合GraphQL Subscription实现实时数据推送，比如聊天消息、订单状态更新、仪表盘实时数据等。
• 内部工具与仪表盘：快速组合不同数据源的数据进行展示，无需为每个工具单独开发API，提升开发效率。

内容的提问来源于stack exchange，提问作者YulePale