GitHub移动版和GraphQL(译文)
By S.F.
本文链接 https://www.kyfws.com/news/2020-09-23-github-mobile-and-graphql/
版权声明 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
- 5 分钟阅读 - 2314 个词 阅读量 0GitHub移动版和GraphQL(译文)
原文地址:https://github.blog/2020-09-23-github-mobile-and-graphql/
原文作者:Hesham Salman
译文由本站翻译
GitHub的移动应用程序已使用GraphQL来提供新功能.现在,我们能够更快地行动,并以更少的麻烦和更多的精力完成更多的工作.
我们能够转向开源社区,并将Apollo用于iOS和Android.通过这样做,我们以惊人的速度前进.我们还最大程度地减少了对移动应用程序核心部分正在进行的工程设计工作.
GraphQL使我们可以将精力集中在网络,建模和API稳定性方面的繁琐工作上.它使我们能够专注于我们真正热衷的事情:建立良好的经验.
GraphQL心态
GraphQL有一些学习曲线.对于在REST环境中工作的人员,这需要改变心态.
GraphQL提供接口,类型,方法以及相关的文档作为数据结构.这为在其上构建工具铺平了道路.这通常称为架构.该模式表示可以修改它们的可用接口,类型和突变. GraphQL世界中没有针对不同响应的端点.因此,思维方式的第一个必要转变是从端点思维到类型思维. GraphQL不是SQL.但是,从SQL模式的角度考虑可能有助于促进思维方式的必要转变.该模式记录了后端的可用数据类型,查询和变异.外部客户端(例如移动应用程序)保留对必须手动更新的架构的引用.
从REST思维方式迁移到GraphQL
从REST思维方式转移到GraphQL意味着将思想从HTTP方法转移出去.您不再考虑GET和POST方法;您现在只考虑操作,例如查询和变异.查询类似于HTTP get.它们是从服务器检索数据的任何操作.另一方面,变异包含其余可能的HTTP操作.每当客户端想要修改服务器上的数据时,就会发生突变.这可以是POST,PUT,DELETE或PATCH.
由于客户端定义了所需的数据,并且端点不存在,因此只要客户端在模式中有效,响应就是客户端想要的.这使客户工程师可以针对他们正在处理的视图编写特定的查询,而不必使用using肿的响应或关联多个端点之间的往返.
尽管思想发生了变化,但GraphQL思维方式实际上没有REST思维方式复杂.有可用的查询类型,可用的变异及其输入.不再考虑端点或响应结构.
代码生成
GraphQL在移动设备上的最大优势之一是为网络响应生成静态类型的代码.能够生成我们的网络模型可以为我们节省大量的时间,精力和维护.
在大多数基于REST的系统中,我们必须手动定义网络模型并考虑编码和解码策略.多年来,虽然iOS的Codable和Kotlin的内置序列化使编码和解码变得更加容易,但这仍然是需要考虑的问题.另外,可编码的实现要求整个模型成为响应的一部分.必须手动将密钥与服务器对应的密钥保持最新,并且响应的结构更改通常会破坏旧客户端的更改.
但是,使用Apollo和GraphQL,我们不再需要考虑应用程序开发的这一基本步骤. Apollo的工具使我们能够静态键入网络响应.这使我们的客户知道并信任他们接收的数据.从那里,我们可以自由地进行转换,并根据需要进行处理.随着后端的更改,每次刷新架构时,我们的模型都会与最新的后端更新保持一致.
由于GraphQL API具有字段级弃用功能,因此可以肯定的是,对后端模型的任何更新都不会破坏我们的移动消费者.
片段
片段是GraphQL的一个可重用的小片段.在GitHub移动团队中,我们是片段的大量用户.我们使用它们来确保跨模型的数据和API一致性.它还减少了模型总数.一个常见的例子是我们的actorFields片段:
在GitHub API中,Actor代表可以执行操作的对象-通常是用户.我们在整个应用程序的大部分部分重复使用此片段.这允许非常一致的模型API.例如,我们所有的移动时间轴事件都有一个或多个演员.通过使用字段,每个GraphQL查询变得更短,并且生成的模型更加一致.
通过重新使用片段,这使我们可以快速提出新的查询和变异.使用片段的更强大的方面是片段是可组合的.我们不限于每种类型使用一个片段.例如,当请求一个用户时,我们可以请求其参与者字段以及与他们的关注者和关注者有关的信息:
这样,我们就可以减少GraphQL查询之间的重复并生成更少的模型-SomeQuery的响应对象包含我们先前已经生成的两个模型.更重要的是,我们现在可以重用和组合已经定义的片段!我们可以创建以特定类型的片段开头的较小的视图模型,然后仅通过组成这些片段即可将它们组合为较大的视图模型.
平台差异
Apollo GraphQL库的iOS和Android实现之间存在明显差异.
iOS和Android(通过Kotlin)都引入了自己的反应式原语.阿波罗(Apollo)对Kotlin的支持还很年轻,但它足以让我们在生产中使用.但是,综合支持仍在继续-在Apollo 路线图中已将其列为长期目标.
此外,某些片段(尤其是在接口上执行的片段)只能在iOS上生成.这很少成为障碍.它通常需要更明确地遵守Apollo-GraphQL识别的类型.
最终,会有一些平台差异,但是它们并不能转化为从一个平台到另一个平台的巨大转变.两种语言之间,由Apollo提供的生成代码非常相似.这意味着它可以以几乎相同的方式使用. Apollo团队还致力于调整和减少Apollo Client项目(网络和移动项目)之间的差异.
在关闭中
GraphQL和Apollo的工具使我们能够高效运行.通过允许我们消除传统上影响移动应用程序的许多问题,我们可以集中精力快速构建功能.此外,我们受益于每个网络请求的每个部分变得有用,而不必自己维护网络响应.
Features Product Andriod Apollo GitHub Mobile GraphQL iOS rest 新闻 翻译