GraphQL 不是 OData 已翻译 44%

oschina 投递于 2018/11/08 12:30 (共 25 段)
阅读 163
收藏 0
0
加载中

几年来,我注意到许多开发人员对GraphQL发表了不明智的声明。人们声称GraphQL允许客户端从服务器进行排序,分页和过滤。人们声称GraphQL可以任意查询或连接。人们声称GraphQL暴露了太多的功能而没有足够的服务器端控制。正如我希望通过这篇文章传达的,这些说法是错误的。

不久前,我看到有人在推特上指责GraphQL。这条推特是我尊敬和钦佩的人,他们经常展示深度和尽职调查,这同样也是他们的声明让我惊讶的原因。评论之一是:“Graphql是odata的一个花哨名称”。让我深吸了一口气,决定不参加。

dafengchui
dafengchui
翻译于 2018/11/19 11:12
0

几年来,我们在 SAP Concur 使用 GraphQL 并取得了很大的成功。几年来,我思考了我过去关于 OData 的经验和 GraphQL 给我带来的幸福。几年来,我作壁上观,尽量不置身其中地去表达,“well, actually…”

最近,我意识到我已经收集了很多我对于 GraphQL 的想法,并且我觉得是时候把它们呈现出来了。我的恼怒归结成一个声明。不知道是否有人注意到,我发布了一条简单的 tweet ,并且准备好和各位进行交流。

GraphQL 不是 OData,能不能别再把 OData 的缺点扣在 GraphQL 头上?

在微软,我根据自己的判断使用并传播 oData。对不起,我无法阻止火车失事。

在 Concur ,我们成功地用 GraphQL 替代了 RESTful APIs。

dubox
dubox
翻译于 2018/12/10 22:57
1

OData 经历

我在微软度过了几年,对一些项目有过贡献,你们可能比较熟悉的:

WCF RIA Services

我在 WCF RIA Services 项目工作时,第一次接触了 OData。在这个项目,我从最开始的 SDE II 做到开发主管。WCF RIA Services 将 Silverlight 和 ASP.NET 连接起来,允许你通过 ASP.NET domain/business层 和Silverlight UI 创建业务线应用。这种组合使得从‘表单+数据’的应用升级到复杂业务逻辑应用变得相当简单,通过清晰分离的关注点保持业务逻辑在 UI 之外。

WCF RIA Services 允许你直接暴露 Domain Model 给客户端或者创建并暴露一个 View Model 。通过编写 CRUDE操作(create, read, update, delete, execute) 和注释,你可以很容易的创建 API 供客户端调用。但是我们需要一个协议来序列化带着CRUDE操作和数据的请求和响应。最后我们落地为使用一些 WCF 原语(primitive)。

dubox
dubox
翻译于 2018/12/12 00:14
0

在我们最终确定采用 WFC 之前,我们的项目叫‘RIA Services’ ,RIA 的意思是‘富网络应用(Rich Internet Application)’。使用 WCF 导致我们的项目名前面加上了 ‘WCF’ ,并且信不信由你,连项目组都被改组并进 WCF 组。尽管这样一切都是好的,WCF 远比我们自己开发的早起预览版的协议要好很多。

WCF RIA Services 真的是相当好的设计。我们当时正在向构建在我们的框架之上的应用推广关注点分离,并且我们自己也保持我们是关注点分离的。这使得服务端和客户端都从通讯协议解耦。我们能够以很小的影响换掉那个层,是因为 Wilco Bauwer 非常了不起。Wilco 只用了几天时间就用 WCF 换掉了我们那个协议。并且我们证明了我们可以支持多协议并行。

dubox
dubox
翻译于 2018/12/13 00:44
0

说到 OData。微软当时还下功夫推了一阵儿。SQL Server组中一些非常精明的人发明了它,并且它背后有‘一股非常强的力量’。很明显地,我们需要为 WCF RIA Services 增加 OData 支持。经过几轮讨论,我们最终的决定是:

  • WCF RIA Services 将支持 OData 作为可选协议

  • 但是 OData 不能作为默认选项

我们随后便在 WCF RIA Services SDK 中创建了 OData 协议库,并且使应用开发者可以轻松的将默认协议更换为 OData。

我不记得在那些讨论中我反对 OData 的那些理由了,但是我记得一个非常清楚地细节,就发生在我们发布了支持 OData 的 SDK 之后 —— 一个 OData 规范的漏洞(vulnerability in the OData specification )它允许远程执行代码并可能导致拒绝服务(DoS)。你可以通过仅仅一个精心设计的 GET 请求就杀死 OData 服务器。额。。。(扎心)

dubox
dubox
翻译于 2018/12/14 00:17
0

NuGet

在重组期间,当 ScottGu 在 Azure 中担任领导时,ASP.NET 组与 WCF 组合并在一起。这为 ASP.NET Web API 等项目开辟了机会。 这也为我扩大在微软的业务范围提供了机会; 我开始研究 ASP.NET 和 NuGet。

当 NuGet 1.5 发布时,我加入了 NuGet 团队。那时,它基本上是一个边缘项目,团队中的每个人也在研究其他产品。 NuGet 是开源的,客户端是通过 CodePlex 下载的,并作为 Visual Studio 的扩展安装。

溪边九节
溪边九节
翻译于 2018/11/19 17:21
0

NuGet 像其他包管理器一样,需要一个公有的仓库。NuGet.org 是我们团队创建的,那是一群恰巧也正在 ASP.NET MVC、 ASP.NET Web Pages、Razor 或者其他几个产品线上工作的伙计们。你能猜出我们被告知我们必须使用什么协议让 NuGet 客户端连接到 NuGet Gallery 吗?

你猜对了:OData

我会记得我们一起喝酒的细节,但是那个选择做的并不好,并且团队几年来一直致力于改变方向。Howard Dierking 和我一起在 NuGet 工作,我们花了大部分时间想办法怎样将 OData 从 NuGet 剥离。

这是我们做的努力所带来的一些启发:

dubox
dubox
翻译于 2018/12/15 01:41
0

GraphQL 经历

2015年,我离开微软加入 SAP Concur。 Howard 差不多早我7个月去了 Concur,在 Simon Guest 带领的新平台团队里工作。

我们团队当时正准备下大功夫重构 UI。Concur 遗留了一整块两层架构的应用,它直接通过 UI 访问数据源(包括数据库)。我们需要分离关注点,将 UI 从那一整块中剥离,开始采用现代 UI 技术并且专注于建立一个可扩展、用户友好、易理解、可持续 UI 层。

我们很快选择了 Node 和 React 作为核心技术。我们还学习了 Flux 架构模式来和 React 的单向数据流互补。我们开始使用 fluxible 和其他 flux 类库,但是当 redux 出现时,redux 替换了所有。

Concur 当时已经在把 API 拆分成微服务;我和 Howard 加入之后也为此投入了几年时间。所以我们应该怎样让 UI 和那么多服务进行交互?

又猜对了: OData

真有意思。。。

dubox
dubox
翻译于 2018/12/16 13:58
0

填补空白

我们很早就开始使用  fetchr  而且非常酷。 Fetchr 给了我们一个协议,并处理很多管道,但它是面向 CRUD 的,我们不喜欢。 我们知道我们想要在我们的 API 和我们的用户界面之间放置一些东西作为外观,但我们不知道在GraphQL 发布之前,什么会填补这个空白。

一旦 GraphQL 可用,Simon 和 Howard 就会全力以赴。 他们知道我们需要投资使用 GraphQL ; 他们看到了将我们的 API 转换为 UI 的需求。 他们赞赏 GraphQL 协议的简单性以及它对客户端和服务器的明确性。 Simon 和 Howard 认识到我们的团队可以独立在 GraphQL 层上构建 API  。

溪边九节
溪边九节
翻译于 2018/11/20 09:37
0

当 Simon 和 Howard 介绍 GraphQL 给我时,我瞬间被收买了。简直醍醐灌顶,短短5分钟我就迷上了它并打算使用它。我们开始将计划落实为行动,接着我们就可以:

  • 创建,部署,和运行一个 GraphQL 服务器,在 Howard 的平台组

  • 将我的组创建的新的 Node/React/Redux UI应用连接到 GraphQL

  • 设计可以跨手机和 web共用的 GraphQL 模式和解析器

  • 将 GraphQL服务器连接到各种有需要的微服务上

  • 甚至将 GraphQL 连接到还没有新 API 的旧 API 上

  • 独立于 UI 和 API 在 GraphQL 层进行逐步更新

 我们在 Concur 已经有两年多使用 GraphQL 的经验了。总的来说是非常正面的。当然,我们也犯过错误;就是在“版本2”的中游,我们该如何在组织上处理 GraphQL。但是我们需要版本2的一个重要原因是——它的使用已经超出了我们围绕它构建的组织结构。就像Conway’s law(康威定律)断言的那样,我们的实现模仿了组织结构,所以我们的实现也将在版本2改变。

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” –Melvin Conway, 1967

------------------------------------------------------------------------

大意:设计系统的组织 。。。都不由自主的将系统设计为跟他们的组织的沟通结构相同

dubox
dubox
翻译于 2018/12/18 02:22
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(0)

返回顶部
顶部