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。 直接用内存也可 {}

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

[graphql](https://www.starlette.io/graphql/)

参考