DAppsの新しいアーキテクチャ設計：GraphQLと標準クライアントに基づく

著者： 冒志鴻（ArcBlock CEO 兼 チーフアーキテクト）

分散型アプリケーション（Decentralized Applications、DApps）のアーキテクチャについて、現在私たち ArcBlock は、GraphQL と標準クライアントに基づいた新しいアーキテクチャ設計を採用しています。

基本コンセプト

1. バックエンド（サーバーサイド）は、REST API ではなく GraphQL を採用してサービスを提供します。

私たちはこれまでに、『OCAP の実装を深く理解する：なぜオープンチェーン・アクセス・プロトコルは GraphQL を採用したのか』や『GraphQL は分散型ネットワークに活力を与える』などの記事で、GraphQL を採用する多くの利点を紹介してきました。興味のある読者の方はぜひご一読ください。バックエンドで GraphQL を実装するのは、REST API を実装するよりも多少の手間はかかりますが、それほど難しいことではありません。

2. 一つの複雑で巨大なバックエンドではなく、多くの小さくシンプルなバックエンドを構築します。

これはマイクロサービスの概念に似ています。つまり、あらゆるロジックをすべてバックエンドのロジックに詰め込むのではなく、可能な限りモジュール化し、各モジュール間を疎結合（ルーズカップリング）にすることです。結合が緩やかで、ステートレスであり、相互依存が少ないほど望ましいと言えます。

3. フロントエンド（Web アプリおよびモバイルアプリを含む）は、バックエンドに依存しない純粋なフロントエンドです。

Web の実装においては従来の Web アプリとは異なります。従来の Web はバックエンドでページをレンダリングするためフロントエンドにロジックがほとんどありませんが、近年流行している React、Vue、Meteor などはすべて、フロントエンド自体がロジックを持つ設計方式です。フロントエンドは GraphQL を介してバックエンドサービスに接続し、データを取得します。この設計により、Web とモバイルアプリでほぼ完全に一致したアーキテクチャを採用でき、Web アプリのモバイル化が容易になります。

4. フロントエンドが完全なアプリケーションロジックを実装し、バックエンドには持たせません。

つまり、そのアプリケーションがゲームとして機能するのか、あるいは取引所として機能するのかは、フロントエンドが複数のバックエンドサービスを組み合わせて形成します。バックエンドはサービスを提供するだけであり、フロントエンドが具体的にどのようなビジネスを行っているのかを知る必要すらありません。

5. フロントエンドを標準化し、異なるバックエンドを柔軟に切り替えられるようにします。

例えば、EC サイトやアプリのインターフェースはどこもほぼ同じであることに気づくでしょう。では、なぜ各 EC サイトは独自のアプリをリリース・運営し、ユーザーはサイトごとにアカウントを登録して、あちこちで支払い情報を入力しなければならないのでしょうか？理想的な EC DApp が標準化された設計を採用していれば、同じインターフェース、同じアプリで、複数の EC プラットフォームでの買い物が可能になります。

実際、多くの技術が長年発展した後、標準化は避けて通れない道となります。例を挙げれば、どのブランドのテレビでも、どのチャンネルが放送するどの番組も視聴できます。どのブランドの車でも、同じ規格であればどのブランドのガソリンも給油でき、給油口も共通です。車両はどの国や地域であっても、同じ規格の道路を走行できます。これが標準化の威力です。

ユーザーデータの一貫性をどのように確保するか

DApps 設計の例

上述の考え方を用いて、「知識星球（Zhi Shi Xing Qiu）」（旧・小密圏）のようなアプリを実現する場合、その設計と実装は従来のアプリとは異なります。

ある開発者が ArcBlock プラットフォームに基づいて「知識星球」のような DApp を開発しようとしていると仮定します。重要な要求は、これらの有料コミュニティが十分に分散化されており、開発者を含むいかなる人物もプライベートな共有コミュニティを閉鎖できないようにすることです。

「小密圏」は当初非常に急速に発展し、ユーザーに愛されましたが、間もなく関係当局によって取り下げ処理が行われました。一部のユーザーがアプリ内で違法なコンテンツを共有したことが、この封鎖決定の重要な要因であったと考えられます。しかし、一部の不正なコンテンツのためにサービス全体が停止してしまうのは非常に惜しいことであり、まさに「赤ん坊を洗桶の湯と一緒に流し出す」ようなものです。

優れた分散型サービスでは、まず多くのノードが存在でき、各ノードが独自のルールを制定できます。ルールに適合しない場合、ノード運営者は自身の判断、あるいは現地の法律に従って処理できます。制限を受けたくないユーザーは自身のノードを運営するか、自発的に連合してノードを運営できます。これらのノードのプロトコルが一貫しており、DID メカニズムを使用してユーザープロフィールを共有し、チェーン上のアセットを使用して支払いとアクセス管理を制御している限り、ユーザーは一つの統一されたクライアントアプリ（Web、モバイルアプリを問わず）で、無数のバックエンドノードに一元的にアクセスできます。

このような設計は、「知識星球」のような分散型のプライベート共有コミュニティを完璧に実現します。各ノードは独自のルールを制定し、コンテンツ管理と法的コンプライアンスを自主的に行います。規約違反のノードが整理・閉鎖されたとしても、サービス全体には影響しません。あるノードのサーバーがダウンした場合でも、単にサーバーを交換して、過去の DID と購入記録を継続して認めることで運用を続けられます。元のユーザーは全く影響を受けず、ノードサーバーが移行したことすら気づかないでしょう。

この DApp を開発したデベロッパーは、分配ルールを策定できます。例えば、全収益の 10% をこのデベロッパーに。各ノードもルールを制定でき、例えば収入の 15% をノード運営者に。各有料共有グループのオーナーは自身の価格を設定します。もしグループオーナーがノードの利用料が高すぎると感じれば、より安価なノードを選択するか、あるいは自身でノードを運営することで、ノードへの配分を全く不要にすることもできます。アプリのデベロッパーは、アプリを良好に維持するだけで、自身の配分を受け取ることができます。アプリデベロッパーはさらに、収入の 50% をフロントエンド開発者に、50% をバックエンド開発者に、といった具合に、独自の分配ルールを策定することも可能です。

出典： ArcBlock 技術コミュニティ