GraphQL学习笔记

Web编程

我这几年对Web编程充满恐惧和排斥。

原因之一是来自社区最佳实践和工具链的剧烈变化，让人疲于奔命。当然近两年好了很多，web社区，尤其是前端社区，关于最佳实践有个更长远的共识。而不是像人们过去吐槽的，请假一周回来，发现大家都在用没见过的新工具/框架。

原因之二是进行Web编程时，大部分时间仿佛在做填空练习，web框架帮你把大多数事情都做好了，你需要做的就是在一些地方填空，把业务需求翻译为REST API。数据存储，检验，序列化，错误信息，API文档，一些成熟的框架会为你包含这其中的许多事，只要你按要求填空，就能一次性完成其中的大多数工作，像https://www.django-rest-framework.org/这类的框架就做得很出色。

这些层层包装看起来都很美好，REST ORM

在不同的地方，命令式编程。

CURD，input/output的工作。其中包含的创造力工作少得可怜。

构建一个小型博客当然是简单的，可以徒手完成所有工作，尽管其中有许多部分你会觉得违背DRY原则，

Web编程是混合式的编程体验，我是指对hacker和全栈工程使而言，他们的焦点总是做一些有意思的事情，通常情况下，他们像一个木匠而不是流水线工人，所以他们想动手完成自己的整个想法，这样一来，他们就不得不社区构建一个网站会牵涉到的所有技术方面：

  • 后端开发
    • 数据库
    • 模版
    • API
  • 前端前端开发 *

GraphQL

https://www.howtographql.com/basics/2-core-concepts/

开发GraphQL是为了满足对更大灵活性和效率的需求！它解决了开发人员与REST API交互时遇到的许多缺点和低效率。

喜欢CGI的思路

不再需要过多和不足

声明需要的东西

“Think in graphs, not endpoints.”

使用GraphQL，可以解决此问题。由于GraphQL具有灵活的特性，因此无需在服务器上进行任何额外工作即可在客户端进行更改。由于客户可以指定确切的数据要求，因此当前端的设计和数据需求发生变化时，无需后端工程师进行调整。

非常爽

模式和类型系统的好处 GraphQL使用强类型系统定义API的功能。使用GraphQL架构定义语言（SDL）在架构中写下API中公开的所有类型。此架构充当客户端和服务器之间的协定，以定义客户端如何访问数据。

一旦定义了模式，前端和后端的团队就可以进行工作，而无需进一步的沟通，因为他们俩都知道通过网络发送的数据的确定结构。

模式定义语言言（SDL） The Schema Definition Language (SDL)

使用REST API时，将从特定端点加载数据。每个端点都有一个明确定义的返回信息结构。这意味着客户端的数据要求已在其连接的URL 中有效编码。

GraphQL中采用的方法完全不同。GraphQL API并不具有返回固定数据结构的多个终结点，而是通常仅公开一个终结点。之所以可行，是因为返回的数据的结构不是固定的。取而代之的是，它完全灵活，可以让客户确定实际需要什么数据。

构建效率能大大提升 想好entity即可！

这意味着客户端需要向服务器发送更多信息以表达其数据需求-该信息称为查询。

rest 非常啰嗦

教程太棒了！ https://www.howtographql.com/basics/2-core-concepts/

带有订阅的实时更新 当今许多应用程序的另一个重要要求是与服务器建立实时连接，以便立即了解重要事件。对于此用例，GraphQL提供了subscriptions的概念。

客户端订阅事件时，它将启动并保持与服务器的稳定连接。每当实际上发生该特定事件时，服务器就会将相应的数据推送到客户端。与遵循典型的“ 请求-响应-周期”的查询和变异不同，预订表示发送到客户端的数据流。（sse？）

查询，变异和订阅

The schema is one of the most important concepts when working with a GraphQL API.

它指定API的功能，并定义客户端如何请求数据。通常将其视为服务器与客户端之间的合同。

GraphQL实际上是与传输层无关的。这意味着它可以与任何可用的网络协议一起使用。因此，有可能实现基于TCP，WebSockets等的GraphQL服务器。

GraphQL也不关心数据库或用于存储数据的格式。您可以使用SQL数据库（例如AWS Aurora）或NoSQL数据库（例如MongoDB）。

GraphQL可用于 在其连接的URL 中有效统一这些现有系统，并将其复杂性隐藏在一个不错的GraphQL API后面。

GraphQL可用于 在其连接的URL 中有效统一这些现有系统，并将其复杂性隐藏在一个不错的GraphQL API后面。

让我们考虑一下GraphQL所带来的主要变化，即从一种命令式的数据获取方法转变为一种纯粹的声明式方法。

所有较低层的网络任务以及存储数据都应被抽象化，并且数据依赖性的声明应成为主要部分。

这正是GraphQL客户端库（例如Relay或Apollo）将使您能够执行的操作。它们提供了一种抽象，您需要能够专注于应用程序的重要部分，而不必处理基础结构的重复实现。

目前有两个主要的GraphQL客户端可用。第一个是Apollo Client，它是社区驱动的工作，旨在为所有主要开发平台构建强大而灵活的GraphQL客户端。第二个叫做Relay，它是Facebook自主开发的GraphQL客户端，它对性能进行了大幅优化，并且只能在Web上使用。

GraphQL的一个主要优点是，它允许您以声明的方式获取和更新数据。换句话说，我们在API抽象阶梯上更上一层楼，不再需要自己处理底层网络任务。

在所有语言层都一样！

GraphQL的一个主要优点是，它允许您以声明的方式获取和更新数据。换句话说，我们在API抽象阶梯上更上一层楼，不再需要自己处理底层网络任务。

太爽了！ web编程很坑 各种记忆规则之前

这个架构 client 可做很多好的优化

GraphQL的一个主要优点是，它允许您以声明的方式获取和更新数据。换句话说，我们在API抽象阶梯上更上一层楼，不再需要自己处理底层网络任务。

高级概念 https://www.howtographql.com/advanced/2-more-graphql-concepts/

GraphQL生态系统现在正以惊人的速度增长。发生这种情况的原因之一是因为GraphQL使我们真正容易地开发出色的工具。

GraphQL生态系统现在正以惊人的速度增长。发生这种情况的原因之一是因为GraphQL使我们真正容易地开发出色的工具。

GraphQL生态系统中可用的许多工具都使用自省系统来提供惊人的功能。想想文档浏览器，自动完成，代码生成，一切皆有可能！在构建和使用GraphQL API时，您将需要的最有用的工具之一会大量使用内省。它叫做GraphiQL现在可以使用以下语法将此。

GraphQL生态系统中可用的许多工具都使用自省系统来提供惊人的功能。想想文档浏览器，自动完成，代码生成，一切皆有可能！在构建和使用GraphQL API时，您将需要的最有用的工具之一会大量使用内省。它叫做GraphiQL现在可以使用以下语法将此。

GraphQL是API 的查询语言 -而非数据库。从这个意义上说，它与数据库无关，可以与任何类型的数据库一起使用，甚至根本不使用任何数据库。

GraphQL的一个普遍关心的问题是维护服务器端缓存的困难，尤其是与REST比较时。使用REST，可以很容易地为每个端点缓存数据，因为可以确保数据的结构不会改变。

另一方面，对于GraphQL，尚不清楚客户端接下来将要请求什么，因此将缓存层放在API后面没有多大意义。

身份验证描述了声明身份的过程。当您使用用户名和密码登录服务并进行身份验证时，便会执行此操作。另一方面，授权描述了权限规则，用于指定单个用户和用户组对系统某些部分的访问权限。

GraphQL是（Web）API的查询语言，从定义上讲，它仅可在线使用。但是，客户端的脱机支持是一个有效的问题。对于某些用例，Relay和Apollo的缓存功能可能已经足够了

https://github.com/howtographql/howtographql 极其出色的教程

python 服务端 https://www.howtographql.com/graphql-python/0-introduction/ 使用

GraphiQL是图形交互的浏览器内GraphQL IDE。换句话说，一个操场。请注意，您需要禁用Django CSRF保护。

GraphiQL有高度的灵活性

django restful 投入巨大的心智负担

重要框架

  • graphql-engine: Blazing fast, instant realtime GraphQL APIs on Postgres with fine grained access control, also trigger webhooks on database events.

    • Hasura可与任何GraphQL客户端一起使用。我们建议使用Apollo Client
    • 中文

  • postgraphile: Execute one command (or mount one Node.js middleware) and get an instant high-performance GraphQL API for your PostgreSQL database!

  • prisma: 新的ORM

    • prisma.io Open-source and self-hosted backend-as-a-service to develop serverless GraphQL backends. 官方推荐prisma。 To learn more about building scalable and production-ready GraphQL servers, be sure to check out Prisma.
    • 跑一个demo。太简单不需要，复杂的话，又没有python熟悉，所以推荐团队使用，而不是自己使用（技术栈优先）

  • graphql-python 使用graphql作为dsl，表达对资源的期待。 契约

  • GraphQL编辑器: 图编辑关系： 无代码解决方案 开箱即用后端模拟，立刻原型 先别管生产环境，先考虑开发原型 改善产品团队内部的沟通 例子 图书馆： https://app.graphqleditor.com/showcase/library

  • graphql-voyager, 可视化graphql API与实体 关注实体

将数据库抽象掉

可以逐步采用，并且可以在您现有的服务（包括REST API和数据库）上分层。

prisma 试用

目标 & 结论

足够可见，被理解

作为服务器，处理许多没预见的问题，而不是被框架束缚

将graphql作为数据查询语言，足够灵活。将其与数据库(prisma/Graphile/Hasura)绑定，则中间部分不可见？ 如何webhook出普通任务（队列、异步任务、log等） 理想情况下，它只是一部分，其他还是可以用nodejs来做。混合后端

我的选择 prisma > hasura > Graphile 支持订阅

先体验 prisma/prisma2 sqlite，完整一个应用。勾出钩子

使用GraphQL编辑器来画出实体，以及关系，用graphql描述API！！ 实现再说

尽可能轻量， 最好sqlite，可携带。

graphql 常规能力，应该是可以有通用后端 搜索 sqlite graphql https://github.com/bradleyboy/tuql

不要太在意这个。 没有问题之前

另一种用法就是作为API语言来用，也很爽。只用Python, 完全轻量。API查询语言. 无限自由。在还不清楚干嘛时。建议这样做。 可以把tinydb都用上。 也兼容restful！ 暴露数据服务 避免时间花在工具上。先去检验需求。 渐进 graphene * 代码处理（细粒度） * ariadne 模式定义 schema-first ， File uploads. Loading schema from .graphql files. 文件上载还不是官方GraphQL规范的一部分，并且不在Graphene中本地实现。 可以直接生成，sdl，通用，而不是手写。 使用了starlette schema = load_schema_from_path(“schema.graphql”) 文档 starlette-integration https://ariadnegraphql.org/docs/subscriptions.html#complete-example 支持订阅！ 数据库单独处理，使用peewee或者tinydb。 直接用内存也可 {}

    使用graphene，解析了过来的数据类型，完全够了，之后的工作 CGI思路来做吧，不要学习更多了，也记不住 不够再说。 兼容众多前端，最重要的 契约好了！  
        使用fastapi吧
    [graphene](https://docs.graphene-python.org/en/latest/types/schema/) 把声明式的变成命令式的了, 像orm
    
[graphql](https://www.starlette.io/graphql/)

参考