GraphQL和微服务

tia*_*ive 13 architecture rest microservices graphql

在我的公司,我们决定为一个新项目提供微服务架构.我们已经了解了GraphQL,并意识到它作为我们的单一API端点使用的潜力和优势.

我们不同意的是如何在GraphQL和每个微服务之间进行通信.有些人认为REST,其他人说我们也应该为每个服务都有一个graphQL端点.

我想知道每个人的优点和缺点是什么.例如,使用graphQL中的所有内容似乎有点多余,因为我们将在每个服务中复制模式的一部分.另一方面,我们使用GraphQL来避免一些REST陷阱.我们担心拥有REST端点会使从gQL中获得的优势无效.

有没有人遇到过类似的困境?我们都不熟悉GraphQL,所以我们可能会缺少一些明显的赞成和反对意见吗?

提前致谢!

vin*_*nce 18

好问题!听起来你在问如何为GraphQL和微服务设置架构,以及为什么.

背景

我建议使用GraphQL,因为它的最佳用例是以一种干净的方式整合数据源,并通过一个标准化的API向您公开所有数据.另一方面,使用微服务的一个主要问题是很难纠缠你可能拥有的所有不同功能.随着应用程序的增长,整合所有这些微服务功能成为一个主要问题.

使用这些技术的好处是巨大的,因为现在您基本上拥有一个GraphQL API网关,允许您从客户端访问您的微服务,就像它是一个单一的整体应用程序,但您也可以从性能和使用微服务获得许多好处效率观点.

建筑

因此,我建议的架构是在您的微服务前面放置一个GraphQL代理,在GraphQL查询和突变解析器中,调用您需要检索必要数据的函数.

在GraphQL微服务之前使用GraphQL网关或在REST端点之前使用GraphQL网关之间的关系并不重要,尽管我实际上认为将微服务函数作为REST端点公开会更简单,因为每个函数都是如此理论上应该只服务于一个目的.在这种情况下,您不需要额外的GraphQL开销和复杂性,因为幕后不应该有太多的关系逻辑.

如果您正在寻找微服务提供商,我见过的最好的是AWS Lambda,Webtask,Azure Functions和Google Cloud Functions.您可以使用Serverless作为管理和部署这些微服务功能的方法.

例如:

import request from 'request';

// GraphQL resolver to get authors
const resolverMap = {
  Query: {
    author(obj, args, context, info) {
      // GET request to fetch authors from my microservice
      return request.get('https://example.com/my-authors-microservice');
    },
  },
};
Run Code Online (Sandbox Code Playgroud)

GraphQL服务

这是我们在Scaphold上一直在探索的内容,以防您希望依靠服务来帮助您管理此工作流程.我们首先提供GraphQL后端服务,帮助您在几分钟内开始使用GraphQL,然后允许您将自己的微服务(即自定义逻辑)作为函数组合附加到GraphQL API.它本质上是最先进的webhook系统,它可以让您灵活地控制如何调用您的微服务.

如果您在该地区,请随意加入SF中的无服务器GraphQL Meetup :)

希望这可以帮助!