graphql java sql_SQL是比GraphQL更好的API语言?

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是用于关系数据转换的成熟通用语言。