拆解GraphQL的特性 – API接口·通用BFF·API网关

2 年 ago
清, 宇
2 minutes
GraphQL.png

GraphQL是一种非常强大的应用（规范），用于构建Web API，但由于具有多个方面的特点，可能很难立即理解。因此，我之前写了几篇文章来解释。

    • GraphQLはサーバーサイド実装のベストプラクティスとなるか

 

    GraphQLの全体像とWebApp開発のこれから

这次我们再次来解释GraphQL，但这次我们想要总结其特点，并简要地介绍一下。希望这能帮助理解GraphQL。

将GraphQL的特点划分为三个部分

我认为GraphQL的特点可以分为三个主要方面（加上生态系统）。

    • APIインターフェスとして

 

    • Universal BFFとして

 

    • API Gatewayとして

 

    (エコシステム)

我們將分別來看。

作为API接口的GraphQL

在GraphQL中，最引人注目的部分很可能是作为API接口的部分。尽管GraphQL有其独特之处，但由于已经被提及过了，所以这次省略不谈。

我觉得只要理解这个部分，从前端的角度来看，GraphQL就足够了。

GraphQL作为API接口的特点是什么？

    • グラフ理論

Tree
Node
AST

Query Language

Query
– 読込系
Mutation
– 書込系
Subscription
– Websocket

Schema

Scalar, Type, List, Enum, Union, Interface, Fragment, Input, Directive

宣言的データフェッチ

クライアントが取得するデータを自由に宣言出来る
Overfetching対策
Underfetching対策
1度のレスポンスに載せられる有効な情報量が多い
複数のクエリを1回のリクエストに含めることが出来る
– リクエスト数削減

単一のエンドポイント

クライアントからするとエンドポイント毎の仕様の違いを知る必要がなくなる

Self-Documenting

Introspection
Schemeがそのままドキュメントになる
別途ドキュメントを作る工数が0
RESTなどで発生する、API仕様の統一化のコストがなくなる

型がある

TypeScriptと相性が良い
React エコシステムとの相性が良い

進化するAPI

インクリメンタルな実装

作为全球最好的朋友GraphQL

从服务器端架构的角度来看，需要理解该特点。

我们先来看一下BFF的特点。

最好的朋友

    • Pattern: Backends For Frontends – samnewman.io

 

    フロント エンド用バックエンドのパターン – Azure Architecture Center
team-ownership.jpg

这是一个在2010年代中期出现的架构模式，它应对了由移动技术兴起引起的多客户端化和容器技术如Docker和Kubernetes的兴起导致的多应用化的挑战。由于客户端和服务器应用程序变得多对多，双方的通信成本（包括通信和人力成本）将被多重化并增加。BFF主要用于减轻客户端的负担，因此每个客户端都会引入BFF。同时，通过将对客户端友好的API实现在资源服务器上，可以实现面向客户端的API设计。

BFF的特点

    • クライアントのためのAPIデザイン

 

    • リソースサーバーからUseCaseを分離する

リソースサーバーの実装負担が減る

あらゆるリソースとつながる

Microservices, Serverless

最適な言語、最適なデータソースを選択出来る
サービス毎のコンピューティングリソースの最適化

変更容易性が高い
レガシーアプリケーションのモダン化

HTTPSオフローディング

gRPCなどの軽量プロトコルに載せ替え

ステートレスな実装

スケールアウト可能

最好朋友的个别问题

在逐步实施个别的BFF时，也会面临一些挑战。

    • BFF間で似たような重複実装になってしまう

 

    • リソースサーバーへのアクセスの多重化は解決されていない

 

    • クライアントごとに作るのでクライアントがある程度大きくなるまでは導入されずらい

それまではクライアントはバックエンド都合で作られたPIでやりくりする必要がある

作为全球最好的朋友GraphQL

apollo.png

引用来源：https://www.apollographql.com/docs/apollo-server/

请提供一种选项的中文释义:
来源：https://www.apollographql.com/docs/apollo-server/

GraphQL在作为所有客户端的BFF行为。继承作为BFF的特征，同时解决了各个BFF存在的问题。

GraphQL作为通用好友和服务接口语言的特点

BFF模式的特征

    • クライアントのためのAPIデザイン

 

    • リソースサーバーからUseCaseを分離する

リソースサーバーの実装負担が減る

あらゆるリソースとつながる

Microservices, Serverless

最適な言語、最適なデータソースを選択出来る
サービス毎のコンピューティングリソースの最適化

変更容易性が高い
レガシーアプリケーションのモダン化

HTTPSオフローディング

gRPCなどの軽量プロトコルに載せ替え

ステートレスな実装

スケールアウト可能

除了。。。之外
附加上。。。

    • 全てのクライアント向けのBFF

 

    • 複数BFFでの問題を解決

重複実装を防ぐ
リソースサーバーへのアクセスの多重化を解決

開発のどの段階でも導入可能(初期、中期、終盤)

作为API Gateway的GraphQL

由于成为全球最佳朋友，能够连接所有客户端和所有资源服务器的中心，因此可以充当API网关。

    マイクロサービスでの API ゲートウェイの使用 – Azure Architecture Center

在终端中提供基于URL的API网关的开放源代码实现有Kong Gateway和KrakenD。在Kubernetes社区中似乎使用了Istio Ingress。在云端，Azure提供了Azure Application Gateway和Azure API Management，AWS则提供了Amazon API Gateway。

GraphQL可以包含与此相同的功能。

由于API Gateway的特点很明确，我会引用KrakenD的特点图像作为参考。

KrakendFlow.png

API 网关的特点

    • Gateway オフローディング

リソースサーバーから共通処理をオフローディングする(認証, ログ, セキュリティ, etc)

複数エンドポイントに比べて、HTTP/1.1のハンドシェイクのオーバーヘッドを軽減出来る
認証サーバーは別途必要(OAuth2.0, OpenID Connect等)

GraphQL生态系统

Apollo Server: メジャーなGraphQLサーバーサイド実装(Node.js)

Apollo Client: メジャーなGraphQL クライアント実装

Apollo Federation: 複数のGraphQLをまとめる。大規模GraphQLを実装する際にサービスを分離できる

Apollo Studio: 監視, メトリクス, 通知を行うサービス

GraphQL Playground: GraphQLをGUIで操作するためのツール

graphql-code-generator: SchemaからTypeScriptなどの型情報としてコード生成するツール

Hasura: CMS as GraphQL + PostgreSQL

AWS AppSync: AWSサービスに接続するためのGraphQL PaaS

总结

我尝试将GraphQL的特点分为三个类别，并通过查看顶部的图表可以更容易理解。当前在日本的前端圈子中，GraphQL稍微引起了一些关注，但似乎只谈及了API接口部分。我认为作为BFF、API网关的最佳实践，GraphQL在服务器端的架构模式中扮演着重要的角色，希望服务器端的人们能理解并接受这些概念。GraphQL作为客户端和服务器端之间的桥梁，只有经过双方的深入了解才能被采用。因此，期待服务器端的理解能够进一步提升。

最后

GraphQL很棒。

如果可以的话，请关注我。@saboyutaka

[追記 2021/07/16] [PR] 我在《软件设计2021年8月号》上为GraphQL写了一篇专题文章。

TH320_642108.jpg
bannerAds