GraphQL将如何以及为什么会影响Sourcehut Alpha

2020-06-11 13:26:31

我经常提醒用户,SourceHut是一个“阿尔法质量的产品”,尽管很多人现在已经在使用它,并且发现它非常适合他们目前的需求。我这样说的意思是要提醒您,虽然很多事情已经开始工作,但在我们投入设计之前,我仍在努力完善实现。这项基础性工作比许多高级功能更重要,因为它将为我们构建和扩展更广泛的SourceHut平台提供基础,使其在未来得到很好的扩展。

今天几乎所有的SourceHut都是使用Python、Flask和SQLAlChemy构建的,这对于快速构建工作原型非常有用。这是构建“良好”服务和理解问题空间约束的有效方法。然而,从长远来看,我已经清楚地认识到,这种方法并不能解决问题,因为它的目标不仅是“好”的,而且是“极好的”。静态类型的好处会使系统变得更稳定,更快、更轻量级的实现会使系统更具可扩展性。总的来说,我在SourceHuthas上的工作真的让我对Python作为大型项目的一种严肃语言的看法变得糟糕起来。

alpha升级到“beta”的核心要求之一是在整个服务中实现完整的API,既供用户访问,也供服务相互通信。这些API的低迷状态是我计划进行的一些大规模更改的主要动机。最初我选择将REST用于API,因为REST乏味且易于理解。乏味的、被广泛理解的方法是采购小屋的面包和黄油。然而,我对结果非常不满意,也不愿意把这个设计推向测试版。在此期间,Alpha是重新考虑此方法并构建更可持续的API设计的最佳时机。

输入GraphQL。我过去曾考虑过GraphQL几次,但由于以下几个原因选择不进一步研究它:

在我的每一次研究尝试中,服务器实现的质量都相当差,特别是在JavaScript实现之外。

生态系统受到网络开发文化的严重影响,而这种文化被SourceHut的理念断然拒绝。这泄露了GraphQL可用的文档和资源,这使得通过SourceHut更保守的值进行评估变得更加困难。

GraphQL没有解决我希望它能解决的许多问题。在我看来,这并不代表我们如何构建一个好的Web API这个问题的最终答案。因此,有一天可能会有更好的技术来取代它,这让我在基于它的长期系统设计上犹豫不决。

GraphQL在一般的Web生态系统中的应用有些缓慢,增值很难理解,更难很好地实现,这使得除了高级工程团队之外的所有人都很难理解。

然而,随着我对REST方法的不满在过去几个月达到顶峰,我对它进行了更认真、更深入的审查。我为git.sr.ht构建了一个Research GraphQL API,艰难地浏览了文档和规范,目的是从SourceHut的角度理解它,以及它如何应用于我们的软件设计观。我还发现(或设计)了GraphQL的一些局限性的解决方案,这让我更有信心,我们可以构建一个不会过时或糟糕的解决方案,当NextThing出现时,它不会让人感觉过时或糟糕。而且,重要的是,自从我上次尝试之后,出现了一个名为gqlgen的新服务器端实现,尽管它不完美,但足以让我认真考虑将其作为大型系统的基础。

GraphQL的另一个(潜在)优势是能够将许多不同的API组合到单个联合GraphQL模式中。如果这成功了,那么访问所有分布式SourceHut服务将非常方便,只需将每个服务或服务子集组合成适合于特定SourceHut部署的简单聚合系统即可。另一个可能被GraphQL改进的研究领域是WebHook:我想尝试使用GraphQL查询注册您的WebHook,这样WebHook有效负载就可以包含处理事件所需的所有信息,而无需任何额外的API请求。

简而言之,我的结论是,GraphQL虽然不完美,但在REST的最新水平上是一个重大的进步,并且足够成熟和成熟,可以作为API的基础和我可以长期信任的实现。这一点非常重要,因为SourceHut的迷你服务的分布式设计需要每个组件之间的高质量通信。在没有达到这个目标的情况下,我不能从Alpha继续前进,而GraphQL让我更有信心很好地实现它。

我在前面也提到过,我对作为SourceHut大部分实现基础的Python/Flask/SQLAlChemydesign不满意。这个设计的性能特点相当差,我可以改进的选择有限。可靠性也不是我特别有信心的,GraphQL的工作本来不会解决这个问题,但它可能会提供一个意想不到的解决方案。

GraphQL服务是完全独立的,可以独立于Web应用程序部署它们。现在,Web服务的Python后端通过SQLAlChemy直接与PostgreSQL通信,但我打算构建通过GraphQL路由的试验性替换后端。这样,更高性能和更健壮的GraphQL后端成为SourceHut中所有信息的唯一真实性来源。如果成功的话,这将大大增强我对系统的信心--Python占用的空间将变得更小、更简单,其中的错误在系统中创建不一致状态的风险也会更小。

这些更改可以并且将以增量方式进行,作为用户,您应该注意到除了性能和可靠性的提高以及对更好的API的访问之外,没有其他更改。我的目的是发扬用户数据,继续支持现有项目,不会造成重大服务中断。今天,SourceHut的性能和可靠性已经是同类产品中最好的,但我认为我们没有理由不能更进一步。我也认为五个九是可以实现的目标。

在撰写本文时,有两个GraphQLAPI可供您使用:meta.sr.ht和git.sr.ht。这些仍被认为是试验性的,一些更大的问题,如写访问和身份验证的改进,仍有待实施。试一试,请分享你的反馈!