SQL是比GraphQL更好的API语言?

20-04-17 banq

Datasette是一个使用SQL实现API查询的项目,Datasette的创建者和Django的共同创建者Simon Willison认为:SQL是比GraphQL更好的API语言。

众说纷纭:

Datasette的口号是“一种用于探索和发布数据的工具”,对我来说,SQL(具有适当的限制)是对数据集执行的各种操作而言是一种合适的API,这在很大程度上是有意义的。这实际上不是典型的Web API用例,通常情况下您会遇到更多专门化和受限的使用场景。

作为Datasette项目的一部分,我已经使用SQL作为API查询语言已有两年,我开始认为用于API查询的SQL确实是一个糟糕的主意。Datasette之所以支持它,是因为它被设计为即席查询工具(恰好能够将结果导出为JSON),但是对于生产应用程序来说,这显然是个糟糕的主意。

我过去曾尝试过几次。我认为我遇到过的最大问题是数据库修改。在这些情况下,我不仅需要更新我的api服务器中的查询,还需要更新我的客户端代码,而对于多个客户端,这变得更加困难。总的来说,我认为客户端上的SQL非常好-甚至很理想。实际上,我尝试开发仅生成用户特定数据库摘录的api,其中SQL非常适合在客户端本地查询数据。去年,由于这个确切的原因,我尝试在浏览器中运行sqlite,但是它太繁琐了。

我认为在这次讨论中变得越来越清楚的是,有一些开发人员(肯定包括我自己)愿意使用SQL作为实际数据库之外的简单编程结构的接口。

我觉得这个讨论很容易使人意识到“在客户端运行任何查询”是一个糟糕的主意,而这正是大多数GraphQL安装程序所提供的优点。尽管我喜欢GraphQL,但当进行安全渗透测试时,它是一个非常方便的数据渗透引擎。默认情况下,没有授权,没有身份验证,甚至带有自省功能。与SQL注入,不安全的S3存储桶或错误配置的NoSQL实例相比,这种技术如果形成流行趋势将对数据安全而言将更加糟糕。

虽然我也看到了许多安全性差的GraphQL API :,但认为GraphQL安全性差似乎是一种不公平的批评。对我来说,GraphQL通常是REST的一种替代方案,后者默认情况下也没有任何授权或身份验证,这是一个正交的问题,但是不能怪罪REST。

GraphQL有意义的是前端进行大量复杂而复杂的调用的情况。如果它是一个简单的REST api,则与其进行交互可能不需要GraphQL,并且实际上可能会对其造成损害。

对我来说,GraphQL仅适合在客户端进行快速原型制作/更改的灵活性很重视时。

实际上GraphQL是让我重新考虑在客户端运行查询是否是个坏主意的事情,这是我开始认真尝试客户端SQL的原因之一。我绝对同意,您必须非常小心安全。根据我在足够大的团队中的经验,有人会在某个时候搞砸,所以在任何客户端查询机制中这都是很大的风险。

就像生活中所有美好的事物一样,这里存在一个折衷。当您所请求的内容最好表示为树(或“图形”,尽管只有DAG变体)时,GraphQL更好。并非总是如此,但是在构建供生产使用的API时通常是这样。当然,您可以用表格形式表示树结构,但是客户端使用它并不十分方便。特别是如果您的客户端正在渲染嵌套的组件视图,则您所需的通常是分层的。GraphQL对我们的生产人员来说更好的另一个方面是性能更可预测,这恰恰是因为该语言受到更多限制。您不仅可以加入所有内容,也不能偶然选择数十亿行。该模式指示允许的内容。当然,同样可以在SQL中进行限制,只需适当地配置您的架构,限制等,但是SQL默认情况下可以执行任何操作,而GraphQL默认情况下则不允许。这就是说,作为一种语言,SQL显然是优越的。它是最成功的4GL(说明性)语言。我希望更多的语言经过精心设计,并希望在此方向上有更多的语言创新。从我的角度来看,GraphQL是一种DSL,用于以JSON格式灵活地从API:请求分层数据,并针对复杂的不断发展的API进行了优化。SQL是用于关系数据转换的成熟通用语言。

HN讨论

 

                   

1
猜你喜欢