我经常提醒用户，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。这些仍被认为是试验性的，一些更大的问题，如写访问和身份验证的改进，仍有待实施。试一试，请分享你的反馈！