オープンチェーンアクセスプロトコルが GraphQL を採用した理由

著者: Jean Chen (VP of PR, ArcBlock)

ArcBlock のエンジニアリングチームは、Open Chain Access Protocol の背後にある設計思想や実装の詳細を「解読」し、公開理解を広げるために、定期的にインタビューを受けたり、エンジニアリングブログを執筆したりしています。設計や製品をさらに改善するためのご提案を歓迎します。

第2回となるこの記事「Why Open Chain Access Protocol Adopted GraphQL」は、ArcBlock のマーケティングチームがエンジニアリングチームへの一連のインタビューを通じて執筆しました。今回初めて、ArcBlock が新世代のクエリ言語である GraphQL を採用した理由に踏み込みます。

現在の世界的な暗号資産市場の低迷にもかかわらず、今年、ブロックチェーン技術は基盤となるパブリックチェーン・プロジェクトの 3.0 時代に入りました。1.0 と 2.0 の時代を代表する Bitcoin と Ethereum は、低性能、使いにくい設計、機能不足、高コスト、プラットフォームの「ロックアップ」などの課題に悩まされてきましたが、次々に登場する新しいパブリックチェーンは、さまざまな技術的解決策を提示しています。

他のパブリックチェーンが、分散型アプリケーション（Dapps）の開発と成功を主眼に、ブロックチェーン技術の普及を推進しているのに対し、ArcBlock が異なるのは、これは新しいパブリックチェーンではなく、アプリケーション開発プラットフォームであるという点です。ArcBlock はクラウド技術を用いて開発者がさまざまなパブリックチェーンにアクセスし接続できるようにし、Dapps の開発に集中できるようにします。これにより、ブロックチェーンアプリケーションの設計は Web ページやモバイルアプリと同じくらいシンプルになります。

Open Chain Access Protocol は、このようなクラウドコンピューティングプラットフォームを構築するための堅固な基盤となります。これは J2EE や Microsoft の .net framework に相当します。このオープンソースのプロトコルは、基盤となるブロックチェーンにアクセスする抽象インターフェース層を提供し、異なるブロックチェーン上で動作するアプリケーションの開発を支援します。データアプリケーションにおける ODBC と JDBC の関係に似ており、Dapps が異なる基盤ブロックチェーンの間を切り替えたり、異なるプロトコルを持つ複数のブロックチェーンを利用したりする場合でも、ビジネスロジックのコードを変更する必要はありません。

開発者が基盤となるパブリックチェーンへ容易にアクセスし接続・切り替えできるようにするために、業界で広く採用されている API クエリ言語である RESTful ではなく、ArcBlock は GraphQL を採用しています。

GraphQL とは何か?

GraphQL は、Facebook が 2012 年に社内で使い始め、2015 年にオープンソース化した新世代の API クエリ言語です。GraphQL の公式サイトでは、コードを使ってその主な特徴を示しています。

API 開発者は API のスキーマを記述し、それに適切な resolver を提供するだけです。クライアントは GraphQL のクエリ形式を使って効率的にデータを問い合わせることができ、サーバーはクライアントの要求に応じた結果を返します。

GraphQL は Query（データクエリ）、Mutation（データ更新）、Subscript（データ監視）の API をサポートします。各 API は resolver を通じてクライアントが望む結果を返します。次の図のとおりです。

GraphQL における graph は有向グラフであり、クエリの各階層はそれぞれ resolver に対応します。そのため、ユーザーが必要とするすべてのデータを取得するために、解決処理は階層ごとに下っていきます。

RESTful と比べると、GraphQL はより効率的で、強力で、柔軟です。クライアント側で問い合わせるデータの構造を定義でき、冗長なデータを返すのではなく、サーバーから同じ構造を返します。

API に GraphQL クエリを送ると、必要なものだけを正確に取得でき、それ以上でもそれ以下でもありません。GraphQL のクエリは常に予測可能な結果を返します。GraphQL を使うアプリは、サーバーではなく自分たちが取得するデータを制御するため、高速で安定しています。

GraphQL のクエリは、1 つのリソースのプロパティだけでなく、それらの間の参照も滑らかにたどります。典型的な RESTful API では複数の URL から読み込む必要がありますが、GraphQL API ではアプリに必要なすべてのデータを 1 回のリクエストで取得できます。GraphQL を使うアプリは、通信速度の遅いモバイルネットワーク接続上でも素早く動作できます。

GraphQL API はエンドポイントではなく、型とフィールドで構成されます。GraphQL は型を使って、アプリが可能な範囲のものだけを問い合わせるようにし、明確で役立つエラーを提供します。アプリは型を使うことで、手動のパースコードを書くのを避けられます。1 つのエンドポイントからデータの機能をすべて利用できます。

要約すると、GraphQL は API 内のデータに対して完全で理解しやすい説明を提供し、クライアントに次の能力を与えます。

Q & A

OCAP のリリースから 1 か月余り後、ArcBlock の創業者兼チーフアーキテクトである Robert Mao、エンジニアリング担当副社長の Tyr Chen、そして OCAP プロジェクトのリード開発者である Peiling Ding が、異なる視点から OCAP 技術に関する質問に答えました。

なぜ OCAP で GraphQL を使うことを選んだのですか?

Robert Mao: 開発者の視点から見ると、GraphQL はシンプルで直感的で、学びやすく、デバッグもしやすいです。クロスプラットフォームでの利用が非常に便利で、フロントエンド開発に適しており、複雑さはバックエンドサーバー側に隠蔽・カプセル化されるため、アプリケーション開発に最適です。ArcBlock はブロックチェーンアプリケーションを支えるプラットフォームであることを考えると、OCAP は多様な基盤ブロックチェーンをサポートする必要があります。しかし現状のブロックチェーンには統一された標準やアーキテクチャがありません。そのため、柔軟なクエリやデータ構造を記述できる言語が必要です。GraphQL の設計はこのシナリオに非常に適しています。GraphQL を使うことで、ブロックチェーン、従来型データベース、Web サービス間の接続と統合を標準化できます。さらに GraphQL には成熟したコミュニティがあり、すぐ使えるツール群も豊富です。

Peiling Ding: ArcBlock は開発者体験を重視しており、それを快適なものにしたいと考えています。クエリ言語としての GraphQL は、フロントエンドの問い合わせをより柔軟かつ効率的にします。業界で最も一般的な手法は RESTful API のセットを提供することです。サーバー側では多数のエンドポイントを用意し、それぞれがいくつかのパラメータを受け取り、いくつかのサービスを提供します。これの見かけ上の利点は、サーバー側で実装しやすく、一般ユーザーもブラウザー経由で簡単にアクセスできることです。しかし欠点は設計が友好的ではないことです。RESTful API では、クエリの開始点はエンドポイントに基づき、それらは緩く組織されているため、クライアント側のコード保守は複雑になり、開発者にとって不親切です。

Tyr Chen: アプリケーション開発の観点では、GraphQL を使うことでクライアント開発者のデータアクセスに対する負担が軽くなります。たとえば Bitcoin の UTXO クエリ要求のように、クライアントがアクセスしたい詳細データに対して RESTful API を使うと、必要のない冗長なデータが返ってきます。なぜなら、必要なのはトランザクションハッシュを問い合わせることだけだからです。GraphQL を使えば、アプリケーション開発者のデータアクセス負荷を大幅に下げられます。まるで SQL でデータベースを問い合わせるようなものです。GraphQL がブロックチェーンデータを問い合わせ、クエリの動作を開始してサーバーに渡すと、異なるデータソースからデータを取得し、クエリの応答を構築して返します。これによりネットワーク伝送データを最適化できます。サーバーはクライアントが必要とするデータだけを返します。

GraphQL は、OCAP が一貫した明快なクロスチェーン操作を実現するうえで、どのように役立ちますか?

Tyr Chen: GraphQL は、OCAP 開発チェーンアクセス層の 3 つのレベルにおける API 定義をよりよく実現しています。たとえば、一次チェーン API の第1層では、OCAP の初版において GraphQL を使うことで Ethereum や Bitcoin などさまざまなデータセットを非常に便利に問い合わせられます。一次チェーン API の第2層では、GraphQL は異なるブロックチェーンの機能を区別できます。Bitcoin と Ethereum は別々に問い合わせられますが、構文構造やユーザーがクエリを書く方法は似ています。開発者は多くの説明を必要とせず、ブロックチェーンへのアクセス能力をあるチェーンから別のチェーンへ容易に移せます。ArcBlock は、開発者向けの OCAP Playground も用意しており、自動補完によりより効率的にクエリを作成でき、記憶コストを大幅に削減し、対応する結果を素早く問い合わせることができます。

Robert Mao: OCAP によって、さまざまなブロックチェーンプロトコルをサポートできるようになります。アプリケーション開発者は、複数の異なるブロックチェーンプロトコル、異なるノードタイプ、異なるデプロイ方式の中から、最適な方法を自由に選べます。オープンチェーンアクセス層は統一 API を定義しますが、これら API の具体的な実装はチェーンアダプターに由来します。

現在のブロックチェーン技術製品では、なぜ GraphQL を使っているものが多くないのですか?

Tyr Chen: Facebook は何年も前から使っていますが、GraphQL はまだかなり新しい技術です。フロントエンドでもバックエンドでも、多くの開発者はまだ RESTful API に慣れています。多くの技術提供者は RESTful 経由でサービスを提供することを好みます。しかし、GraphQL を使う人は今後ますます増えると私は考えています。加えて、GraphQL にはサーバー側で多くのハードルがあります。

Peiling Ding: ブラウザーをベースにした、リンクされたデータアクセスサービスを作るなら、従来の RESTful API を選ぶでしょう。というのも、人に GraphQL を学ばせることはできないからです。サービスの対象という点で、ArcBlock は他社とは異なります。とはいえ最終的には、誰もがブラウザーを開き、URL を入力してオンラインにアクセスするのです。

ArcBlock は GraphQL の既存リソースをどのように有効活用し、GraphQL コミュニティにどのように貢献できますか?

Robert Mao: Facebook は GraphQL をオープンソース化しましたが、公開しているのはフレームワーク言語のみで、具体的な実装方法は提供していません。そのため、GraphQL を使って OCAP を開発する過程で、私たちは多くの探求と革新を行ってきました。私たちは単に「教条を借りている」のではなく、GraphQL コミュニティに対してブロックチェーン領域の空白を埋める貢献をしています。私たちの技術力を考えれば、ArcBlock が最初になるべきです。私たちはこの動きを始め、コミュニティの開発者たちが GraphQL を使って OCAP のチェーンアダプターや blocklets を開発し、私たちの初期の貢献の上に構築していくことを促したいと考えています。また、ハッカソンのようなイベントを GraphQL コミュニティと協力して開催し、双方にとって利益のある協業を行うことも喜んで行いたいと思っています。