高レベルの観点から、HasuraとWunderGraphはどちらも、Hasuraが言うように、「すべてのデータでインスタントGraphQL」を提供します。この記事では、2つのソリューションを分類し、機能ごとに比較します。私たちはおそらく偏見を持っていますが、実際に各ソリューションの長所と短所を調べて、可能な限り客観的に保つようにしています。
私たちはHasuraを会社として尊重し、GraphQLコミュニティのために多くのことを行ってきました。製品の観点からは、両方のソリューションが異なる哲学に従っている一方で、一部の領域で重複があると考えています。この投稿では、類似点と相違点の両方を発見し、どのソリューションをいつ使用するかについてのガイダンスを提供したいと考えています。
機能比較＃
すべてのデータのインスタントGraphQL ＃
Hasuraの主な焦点は、データベース上にGraphQLAPIを生成することです。PostgreSQL、MS SQL Server、Amazon Aurora、GoogleBigQueryをサポートしています。ただし、ドキュメントを見ると、主にPostgreSQLに焦点が当てられています。
APIに関しては、REST、GraphQL、ODataを使用することも可能です。最近、Hasuraは、生成されたGraphQLAPIをRESTエンドポイントに変換するためのサポートを追加しました。
WunderGraphは、PostgreSQL、MySQL、AWS RDS、AWS Aurora、AWS Aurora Serverless、MariaDB、SQLite、Microsoft SQL Server、Azure SQL、MongoDB、Planetscaleをサポートしており、CockroachDBも間もなく登場します。内部的には、WunderGraphはPrismaを使用してデータベースと対話します。つまり、Prismaでデータソースが利用可能になると、WunderGraphに追加できるようになります。
APIに関しては、WunderGraphはREST APIとGraphQLをサポートしており、Apollo FederationwithSubscriptionsも含まれています。つまり、WunderGraphはGraphQLアップストリームをサポートするだけでなく、複数のサブグラフを他のサービスとフェデレーションするApolloフェデレーションゲートウェイとしても機能します。
私たちが知る限り、Hasuraのリモートスキーマ機能はサブスクリプションをサポートしていません。WunderGraphを使用すると、複数のGraphQLアップストリームとApolloフェデレーションを使用している場合でも、GraphQLサブスクリプションがサポートされます。
これまでのところ、2つの間にいくつかの違いがあることがわかりますが、どちらのツールもほぼ同じ機能を提供します。
ただし、すでに1つの大きな差別化要因があります。Hasuraは、データベースを持つという考えに基づいて構築されています。データベースがないと、HasuraAPIを作成できません。
一方、WunderGraphはデータベースにまったく依存していません。RESTおよびGraphQLAPIのみからスキーマを自由に作成できます。それは私たちの哲学が少し違うからです。
Hasuraはデータベースをすべての中心に置いています。中央データベーススキーマから始めて、APIを使用してそれを拡張できます。
WunderGraphはAPIを中心に置いています。APIは、REST API、GraphQL API、1つ以上のフェデレーションサブグラフ、またはデータベースなど、何でもかまいません。その意味で、データベースは単なる別のAPIです。
リモートスキーマ＃
Hasuraにはリモートスキーマの概念があります。何かがリモートである可能性がある場合、それは非リモートスキーマ（中央データベースのスキーマ）も存在することを意味します。さらに、リモートスキーマフィールドと中央データベースの間に関係を構築する方法があります。
WunderGraphは、リモートスキーマと非リモートスキーマを区別しません。代わりに、すべてがリモートスキーマです。これは、任意のAPI間の関係を構築できることも意味します。GraphQLAPIをRESTAPIと組み合わせて、2つの間の関係を構築できます。
前述のように、Hasuraリモートスキーマには、サブスクリプションのサポートの欠如など、いくつかの制限があります。
セットアップと構成＃
構成に関しては、両方のツールは完全に異なるパラダイムに従います。
HasuraはRESTAPIを介して構成できますが、構成の主な方法はユーザーインターフェイスです。データベースの追加からリモートスキーマと関係の構成まで、すべての構成はユーザーインターフェイスを使用して実行できます。このパターンは、習得が容易なため、優れたオンボーディングエクスペリエンスを提供します。
WunderGraphには、構成用のユーザーインターフェイスは付属していません。これは、APIなどのインフラストラクチャをUIを使用して構成する必要があるとは考えていないためです。APIは進化するシステムであり、常に変化し、前進しています。行われているすべての変更を追跡することが重要であると私たちは信じています。開発、ステージング、本番など、さまざまな環境でAPIを操作したいと考えています。また、フォームとボタンは、複雑なAPI環境を構成するには制限が多すぎると考えています。
そのため、ユーザーインターフェイスを介した構成に反対することにしました。代わりに、WunderGraphには強力なTypeScriptSDKが付属しています。このSDKを使用すると、環境を非常に簡単に構成し、すべての構成をgitに保存できます。設定のバージョン管理をすぐに利用でき、簡単に確認してロールバックでき、さまざまな環境でブランチを使用できます。変更がステージングでテストされると、本番環境にマージできます。WunderGraphは、これらのフローをサポートするようにゼロから設計されています。
したがって、ユーザーインターフェイスを使用してAPIを構成したい場合は、Hasuraに傾倒する可能性があります。「コードとしてのインフラストラクチャ」に興味がある場合は、WunderGraphの方が適しています。
認証＃
Hasuraは認証を処理しないため、別のサービスを統合するか、独自にソリューションを構築する必要があります。
WunderGraphを使用することで、すばらしい認証開発者エクスペリエンスを構築するためにさらに一歩前進しました。認証のためにOpenIDConnectをサポートするだけでなく、構成された認証プロバイダーで認証する方法を知っている完全にタイプセーフなクライアントも生成します。簡単に言うと、Keycloak、Auth0、Oktaなどの認証プロバイダーを構成します。これにより、認証フローを処理するバックエンド機能と、クライアント側の部分を処理するクライアントが生成されます。関数をユーザーインターフェイスに接続するだけlogin()で、ログインが完了します。この機能の詳細については、ドキュメントをご覧ください。
承認＃
Hasuraは、役割ベースのアクセスモデルを介して承認を実装しました。さらに、行レベルのセキュリティを使用することもできます。これは、データベースに非常に近いツールにとって意味があります。アクセス許可は、Hasuraダッシュボードを使用して構成できます。リモートスキーマを使用すると、状況が少し複雑になります。各ロールのSDLを使用して特定のスキーマを定義し、アクセスを制限できます。別の方法として、ヘッダーをリモートスキーマに転送することもできます。
私の観点からは、ロールベースのアクセスは非常に堅実なソリューションのようです。特に、行レベルのセキュリティをサポートするPostgreSQLのようなデータベースで使用する場合はそうです。とはいえ、リモートスキーマの承認は、システムが最適化されていないエッジケースのようです。
WunderGraphは、承認に関して異なる意見を持っています。認証用のOpenIDConnect統合があります。つまり、ユーザーはすぐに使用できるIDを持っています。このアイデンティティは、WunderGraph自体によって駆動されるものではありません。信頼できる情報源はIDプロバイダーです。つまり、IDプロバイダー内からユーザーを構成および管理できます。ユーザーに付与するロールと権限に応じて、ユーザーにはさまざまな「クレーム」があり、WunderGraphAPIと対話するときに使用できます。
クレームインジェクション機能を使用すると、IDプロバイダーからのクレームを使用して、それらをGraphQLオペレーションに直接インジェクトできます。クレームインジェクションのトピックについて詳しくは、こちらをご覧ください。この機能の威力の簡単な例を挙げましょう。
この操作を実行すると、ユーザーに代わって投稿が作成されます。変数NAMEとEMAILは自動的に操作に注入されます。
つまり、データベースがPostgreSQLなどの行レベルのセキュリティ（rls）をサポートしている場合は、ユーザーの電子メールを挿入して、そのことを許可することができます。
さらに、TypeScript関数を記述して、操作を実行する前にユーザーのクレームを検証できるフックがあります。つまり、IDプロバイダーによって定義されたユーザーの役割と権限を評価することで、API、ファイルのアップロード、変更などへのアクセスを制限できます。これにより、構成を維持しやすくしながら、完全な柔軟性が得られます。
その上、WunderGraphにはロールベースのアクセス制御の実装が付属しています。ユーザーが初めて認証するときに、TypeScript関数を使用してユーザーに役割を割り当てることができます。たとえば、メールアドレスに基づいてさまざまな役割を与えることができます。TypeScriptフックは単なるNodeJSであるため、外部システムまたはデータベースからデータをフェッチして、ユーザーに役割を割り当てることもできます。@rbac役割が割り当てられると、ディレクティブを使用してオペレーションを保護できるようになります。
この例は、ロールを持つユーザーのみがsuperadminユーザーの電子メールによるメッセージの削除を許可されていることを示しています。
このセクションを要約すると、HasuraとWunderGraphの両方が、APIの承認を実装する多くの方法を提供します。私がする唯一の違いは、WunderGraphs認証システムが多くの「リモートスキーマ」でうまく機能するように設計されていることです。一方、HasuraはPostgreSQLのネイティブ機能を使用したいときにうまく機能します。
APIセキュリティ＃
GraphQL APIを公開するということは、セキュリティについて慎重に考える必要があります。GraphQL APIのセキュリティ保護の複雑さについてより多くの洞察を得たい場合は、ブログ投稿でこのトピックについて広範囲に記述しました。
Hasuraは、この問題に対処するための多くの機能を提供します。それらの中には、深度制限、ノード制限、レート制限、本番環境でのイントロスペクションの無効化、リストの許可があります。
彼らが誤解しているように見えることの1つは、CORSの使用です。CORSはサーバーを保護しているのではなく、ユーザーを保護しています。ユーザーが認証されて別のドメインにアクセスしている場合、CORSを使用すると、ユーザーが別のドメインにいる場合でも、ユーザーからの認証情報を受け入れるかどうかを制御できます。ただし、Hasuraは認証にJWTを使用しているため、攻撃者がJWTトークンを盗むだけでよいため、このシナリオはほとんどありません。CORSは、Cookieベースの認証を使用する場合に意味があります。
WunderGraphは、APIセキュリティについて異なる考え方をしています。私たちの意見では、GraphQL APIを公開することは、あなたが入りたくないうさぎの穴です。いたちごっこです。スキーマ全体が安全であることを証明することはほとんど不可能です。できる限りのことをしたと思っていても、ハッカーはシステムを悪用する機会を見つける可能性があります。
GraphQL APIを公開して保護しようとする代わりに、JSON-RPCAPIのみを公開します。開発中に、必要なすべての操作を定義します。これらはすぐにJSON-RPCAPIに変換されます。このJSON-RPCAPIは変数のみを受け入れ、認証およびJSON-Schema検証ミドルウェアによって保護されます。
JSON-RPCは使いにくいため、JSON-RPC APIに基づいて100％タイプセーフなクライアントを生成するコードジェネレーターも作成しました。後でこのクライアントに戻ります。
入力検証＃
前の章で説明したように、WunderGraphは、定義したGraphQL操作ごとに専用のエンドポイントを作成しますが、それだけではありません。操作の入力と応答の両方をJSONオブジェクトとして表現できます。WunderGraphは、各操作のGraphQL ASTを解析し、そのJSONスキーマを生成します。このようにして、オペレーションの入力を簡単に検証できます。
カスタムディレクティブのおかげ@jsonSchemaで、操作定義内から直接JSONスキーマ検証を拡張することができます。これは、JSONスキーマを拡張するために、タイトル、説明、および正規表現パターンを追加する例です。
このアプローチの優れている点は、生成されたJSONスキーマをアプリケーションの他の部分（フロントエンドなど）で再利用できることです。これの優れた用途の1つは、react-jsonschema-formとの統合です。ライブラリはJSONスキーマも取得できるため、GraphQLオペレーションを作成するだけで、完全なReactフォームを生成できます。
Hasuraは、入力検証にPostgresチェック制約またはトリガーを使用することを提案しています。もう1つのオプションは、次の章で説明するカスタムHasuraアクションを使用することです。
個人的には、入力の検証はデータベースに依存すべきではないと思います。すべてのデータベース管理システムが同じ機能を提供するわけではありません。また、入力が無効な場合は、できるだけ早く動作を停止できるようにしたいと思います。最後に、アプリケーションを構築するときに特定のデータベースに依存したくありません。私の意見では、APIゲートウェイレベルでのJSONスキーマ検証は、入力検証の問題に対するクリーンなアプローチです。
APIのカスタマイズ＃
APIを生成する場合、カスタマイズは常に重要な側面です。WunderGraphとHasuraはどちらも拡張性の異なる方法を提供しているので、それらを分解してみましょう。
まず、ハスラには「アクション」と呼ばれるものがあります。アクションは、REST APIに裏打ちされた、スキーマへのカスタム追加です。したがって、GraphQL SDLを使用してカスタム拡張機能を定義し、それを実装するようにRESTAPIWebhookを構成できます。REST APIはユーザー自身がデプロイする必要があるため、デプロイメントと操作が複雑になります。ダッシュボードには、アクションの構築を簡素化するためのコードジェネレーターも用意されています。
アクションの他に、Hasuraにはイベントトリガーとスケジュールトリガーもあります。これらは、特定のイベントで呼び出すことができます。たとえば、行がデータベースに挿入されたとき、またはcron定義に基づいて呼び出すことができます。
最後に、前に説明したように、Hasuraではリモートスキーマを追加できます。
WunderGraphソリューションに移ります。まず、最初に概説したように、WunderGraphにはリモートスキーマの概念はありません。すべてのスキーマはリモートです。WunderGraphは、OpenAPI仕様（OAS）を内省することにより、RESTAPIもサポートします。したがって、SDLを使用してスキーマを拡張し、WebHookを使用して変更を実装する代わりに、逆の方法をとることができます。OASまたはGraphQLを使用してRESTAPIまたはGraphQLAPIを定義し、それをグラフにマージするだけです。これははるかに便利で、既存のRESTAPIを統合グラフに簡単に追加できます。
第二に、WunderGraphはアクション、フックと同様の概念を持っています！すべての操作はJSONスキーマによって定義されているため、このスキーマを再利用してフックの構造を足場にすることができます。したがって、新しいオペレーションを定義したり、既存のオペレーションを変更したりするたびに、フックを定義するコードを再生成します。現在、TypeScriptを使用してフックを作成できますが、必要に応じて任意の言語でフックを生成できます。フックの型定義は自動的に生成されるため、入力または応答を変更するかどうかに応じて、必要なフックを実装するだけです。たとえば、変更前、クエリ後、同期または非同期です。
また、フックを展開する必要はありません。WunderGraphは、TypeScriptコードのバンドルと、ゲートウェイとの並行実行を自動的に処理します。フックはプレーンなNodeJSを使用するため、任意のnpmパッケージを使用できます。これらすべてにより、フックは非常に強力で、摩擦がなく、使いやすくなっています。
嘲笑＃
APIのライフサイクルの重要な側面の1つは、モックです。実際のシステムに対してテストしたくない場合や、開発中にシステムが利用できない場合があります。
そのため、モックのファーストクラスのサポートをWunderGraphに直接組み込みました。各オペレーションにはJSONスキーマで定義された明確な入力と出力があるため、ユーザーがオペレーションの応答をモックするために使用できるTypeScriptスケルトンを簡単に生成できます。
1つ以上の関数を実装するだけで、モックの準備が整います。スケルトンはTypeScriptを使用して生成されるため、モックを作成する際に型の安全性に依存できます。さらに、舞台裏でNodeJSを使用しているだけなので、フェイカーjsなど、モックを実装する任意のnpmパッケージを使用できます。また、デプロイメントの面倒を見る必要はありません。すべてフレームワークによって管理されます。
Hasuraのドキュメントを見ると、モックに関する情報は見つかりませんでした。彼らの主なユースケースはPostgreSQLデータベースの前に置くことであるため、このデータベースが存在しないことはおそらく非常にまれであり、このユースケースではモックはそれほど重要ではありません。
特に、多くのAPIと統合するシナリオでは、開発中にすべての「実際の」APIを使用できるとは限らないため、モックは開発プロセスに不可欠であると思います。たとえば、送金用のユーザーインターフェイスを構築する場合などです。
ローカル開発＃
WunderGraphは、ローカル開発を最大限にサポートし、優れたオンボーディングエクスペリエンスを作成するために、ゼロから慎重に設計されています。私たちのバイナリは、MacOSarm64やWindowsを含むすべての主要なプラットフォーム用にコンパイルされています。
新しいWunderGraphプロジェクトを最初から始めるのは、次のように簡単です。
これにより、最初に多くの例を含む完全なWunderGraph対応のNextJSアプリケーションが作成されます。
Hasuraを使用する場合、ローカル環境で起動して実行するには、複数のステップのプロセスに従う必要があります。どちらのサービスも基本的に同じ結果をもたらします。WunderGraphがオンボーディングプロセス全体を自動化して、可能な限り流暢にできるようにしただけです。
監視と可観測性＃
Hasuraは、可観測性に関して、大量の情報を提供します。クエリの時間、実行時間、クライアントのIPアドレス、低速クエリの識別、エラートラッキング、分散トレース、WebSocket接続のモニタリング。
可観測性に取り組むWunderGraphでの私たちの計画は2つあります。1つは、Datadog、Splunk、OpenTracing、OpenTelemetryなどの一般的な分析および可観測性ソリューションの統合を構築したいと考えています。一方、将来的には、すぐに使用できる優れた分析ソリューションを提供するマネージドソリューションを提供したいと考えています。このようなソリューションに興味がある場合は、お問い合わせください。
キャッシング＃
キャッシングは、すべてのアプリケーションの重要な側面です。アプリケーションの復元力を高め、パフォーマンスに貢献できる場合は、アプリケーションのすべてのレイヤーでキャッシュを使用する必要があります。
Hasuraでは、LRUキャッシュを使用してGraphQL操作をキャッシュできます。彼らは、ユーザーが指定された存続時間で個々の操作をキャッシュできるようにするカスタムディレクティブを作成しました。このキャッシュのレイヤーはGraphQLの実行に適用されることに注意してください。
Hasuraは、パフォーマンスを向上させるためにPostgreSQLプリペアドステートメントも使用しています。このようにして、SQLクエリプランをキャッシュして、再利用できるようにすることができます。さらに、リモートのGraphQLAPIをキャッシュすることも可能です。
最後に、Hasuraは、「従来の」キャッシングを有効にするためにRESTAPIを生成することを提案しています。私は個人的にそれを伝統的なものとは呼びません。Webのさまざまなレイヤーを見ると、ブラウザー、プロキシ、CDNがわかります。
リアルタイムサブスクリプション＃
Hasuraのコア機能の1つは、ポーリングを使用してPostgreSQL上にGraphQLサブスクリプションを提供することです。Hasuraの賢いエンジニアのおかげで、非常に拡張性の高いシンプルなソリューションです。彼らは、同じSQLクエリを使用して複数のサブスクリプションの「ポーリング」を実行できるようにSQLASTを最適化することを達成しました。
WunderGraphも同様のアプローチを行います。また、ポーリングを使用して「ストリーミング更新」を実装しています。操作ごとのレベルでポーリング間隔を構成できます。つまり、各操作の「活性」を調整できます。さらに、ポーリングはデータベースだけでなく、GraphQLやRESTを含むすべてのデータソースに対して機能します。
もう1つの違いは輸送です。Hasuraは、保守されていないHTTP1.1仕様であるWebSocketに依存しています。WebSocketは、Webで非常に貧弱なAPIを提供します。たとえば、アップグレードリクエストでヘッダーを送信することはできません。そのため、WebSocketを介して認証を実装するためのカスタムソリューションを見つける必要があります。これらのソリューションは通常、APIトークンをブラウザに公開しますが、これは一般的に安全ではありません。
一方、WunderGraphは、サブスクリプションをHTTP / 2ストリームとして公開し、HTTP / 2が利用できない場合は、チャンクエンコーディングにフォールバックします。このようにして、強力な暗号化を備えた安全なHTTPのみのCookieを使用して、APIトークンをブラウザーに入れないようにすることができます。
HasuraとWunderGraphはどちらも、リアルタイムサブスクリプションのソリューションを提供し、WunderGraphはセキュリティにもう少し重点を置いています。
ファイルのアップロード＃
アプリケーションを構築するということは、構造化されたデータだけでなく、画像やPDFなどの形式のファイルも処理することを意味します。別のシステムを使用してファイルのアップロードを管理すると、多くのオーバーヘッドが発生することがわかりました。その場合、認証を2回実装する必要があり、システムが複雑になります。
ユーザーにこの負担をかける代わりに、私たちはさらに一歩進んで、WunderGraphにネイティブファイル管理サポートを追加しました。S3互換のファイルストレージをプラグインして、オンプレミスのMinio、クラウド内のAWS S3、またはその他のS3API互換のストレージプロバイダーにファイルをアップロードできます。このトピックの詳細については、ドキュメントをご覧ください。
Hasuraは、非構造化データをサポートせず、GraphQLAPIのみに焦点を当てることを決定しました。1つの問題に焦点を当てることが良い決断である場合があります。WunderGraphを使用して、ユーザーがあまりにも多くの依存関係を一緒にパズルする必要がないように、エンドツーエンドのソリューションを提供したいと考えています。
クライアントとサーバー間の緊密な結合＃
生成されたGraphQLAPIに対する私の最大の批判の1つは、クライアントとAPI実装の間に緊密な結合を導入することです。APIがデータベースから生成された場合、データベースを変更すると、クライアントに重大な変更が自動的に導入されます。これは、単一の開発者または小規模なチームの場合はうまく機能しますが、複数のチームを持つ組織全体に拡張することはできません。APIを壊すことなく、データの保存方法を変更できるようにする必要があります。
この問題は、ハスラに非常によく見られます。テーブル名またはフィールドを変更すると、APIコンシューマーは重大な変更に対処する必要があります。
すでに学んだかもしれませんが、WunderGraphはGraphQLAPIを直接公開していません。代わりに、オペレーションを使用してJSON-RPCエンドポイントを定義しています。エンドポイントごとに、特定の入力と出力を持つ単純なREST APIのように動作するため、Postmanコレクションを生成できます。
GraphQLスキーマの前にこの「中間」RPCAPIを配置することの追加の利点は、クライアントとのAPIコントラクトから実装を抽象化できることです。分析を通じて、どのクライアントがどの「RPCオペレーション」を使用しているかを正確に知ることができます。これにより、RPCコントラクトを壊すことなく、APIの完全な実装を交換できます。データベースを変更したり、カスタムGraphQL APIに置き換えたりすることもできます。既存のクライアントのRPCコントラクトを実装するミドルウェアを実装するだけで、何も壊さずに変更を加えることができます。これについては、バージョンレスAPIに関するブログ投稿で詳しく説明しています。
バージョンレスAPIは、企業がAPIを使用して共同作業できるようにするための鍵であると信じています。チーム間または企業間でのAPI統合は、チーム間の契約が安定している場合にのみ拡張できます。APIを長期間下位互換性のあるものにすることは、これらの安定した契約を構築するための鍵です。
生成されたクライアント＃
WunderGraphは、バックエンドを生成するためのソリューションであるだけでなく、作成したAPIと連携して動作する100％タイプセーフなクライアントを生成するためのコードジェネレーターも付属しています。オペレーションを定義すると、WunderGraphはAPIエンドポイントとクライアントの両方を生成します。現在、TypeScriptとReactJSをテンプレートとしてサポートしていますが、独自のカスタムテンプレートを使用してこれを拡張し、任意のプラットフォーム、言語、またはフレームワークのコードを生成できます。
認証対応データフェッチ＃
バックエンドだけでなくAPIクライアントも生成することには、多くの追加の利点があります。それらの1つは、認証対応のデータフェッチです。
WunderGraphコードジェネレーターがクライアントを生成した時点で、すべての操作と、ユーザーの認証が必要かどうかを認識しています。開発者は、構成パラメーターを使用してこれを変更できます。
この情報により、操作に認証が必要かどうかを認識できるようにクライアントを生成できます。操作でユーザーの認証が必要な場合、クライアントはこの要件が満たされるまで自動的に「待機」します。操作を試行して401が無許可になる代わりに、クライアントは、要求を行うための前提条件が（まだ）満たされていないことをすぐに示すことができます。さらに、ユーザーが認証すると、クエリまたはサブスクリプションをすぐに起動してデータをロードできます。開発者は、これらの状態を処理するために追加のロジックを作成する必要はありません。
Hasuraはクライアントを生成しないため、このロジックを自分で実装する必要があります。
CSRF保護＃
APIのもう1つの重要な側面は、セキュリティです。重要なのは、ユーザーが意図せずに状態を「変更」する状況にだまされないようにすることです。つまり、APIユーザーが意図したときにのみ送金するようにする必要があります。
この問題を解決するための標準化された方法があり、CSRF保護としてよく知られています。ユーザーがドメインで認証されている場合、CSRF保護により、別のドメインからのリクエストが簡単に変更できないようになります。CSRF保護の実装は簡単ではなく、セキュリティに関するある程度の知識が必要です。
バックエンドとAPIクライアントの両方を生成しているため、両方にCSRF保護を組み込むことができました。WunderGraphを使用してミューテーションを定義すると、結果のAPIは自動的にCSRFで保護されます。何もする必要はありません！
クロスAPI参加＃
HasuraとWunderGraphはどちらも、API間でデータを結合することをサポートしています。Hasuraはスキーマレベルで結合を行い、WunderGraphは操作レベルで結合を行います。
Hasuraから始めて、両方のソリューションを調べて比較してみましょう。
HasuraがクロスAPI結合にアプローチする方法は、ユーザーが既存のデータベース駆動型APIにリモートスキーマを追加できるようにすることです。次に、データベーススキーマとリモートスキーマのフィールドを結合するために使用する引数（外部キー）を構成できます。
その結果、データベース駆動型スキーマとリモートスキーマの両方を組み合わせた新しいスキーマが作成されます。APIユーザーは、2つの異なるAPIからのデータを結合していることに気付くことはありません。これは、単一のGraphQLAPIであるためです。
このアプローチは「スキーマステッチ」と呼ばれ、コミュニティで広く使用されています。
WunderGraphでは、しばらくの間Schema Stitchingを検討してきましたが、これをAPIに参加するための主要な方法にしたくないと判断しました。スキーマスティッチングとApolloFederationは、WunderGraphによってAPIを結合するためのサポートされている方法ですが、新しいアプローチであるネストされたクエリタイプの結合も開発しました。説明させてください。
WunderGraphの目標は、APIを、レゴブロックなど、他のAPIと組み合わせて問題を解決できる小さなビルディングブロックにすることです。
Schema Stitchingで実験を行ったところ、スケーリングを困難にするいくつかの制限があることがわかりました。ステッチしようとしているAPIが多いほど、複雑さが増します。参加するAPIの数が増えると、名前の衝突など、ますます多くの問題が発生します。これらの問題を解決するには、メンテナンスが困難になるカスタムステッチロジックを追加する必要があります。
この問題に対する私たちの解決策は2つあります。まず、名前の衝突を避けるために名前空間を使用します。次に、オペレーションレベルでクロスAPI結合を実装しました。
これは何を意味するのでしょうか？例を見てみましょう：
この操作は、コードによって国をフェッチし、天気APIから天気データを結合します。これを機能させるためにいくつかの特別なディレクティブを使用していますが、最も重要なのは、100％有効なGraphQL操作です。IDEのような既存のツールは、操作を検証でき、インテリセンスとコード補完は期待どおりに機能します。
仮想グラフに必要な数のAPIを追加できるため、このアプローチは適切に拡張できます。名前空間により、各APIが個別に保持され、既存のコードを変更することなく、新しいAPIを簡単に追加できます。
WunderHub-APIのパッケージマネージャー＃
WunderGraphは、安全なアプリケーションをより高速に構築するためのオープンソースフレームワークであるだけでなく、新しいレベルのAPIコラボレーションを可能にする強力なツールも付属しています。
チームで作業していて、APIを同僚、組織全体、または他社の開発者と簡単に共有したいとします。
WunderHubを使用すると、APIを共有し、既存のアプリケーションに統合する簡単な方法が提供されます。WunderGraphエコシステムに緊密に統合されているため、優れたコラボレーションエクスペリエンスが可能になります。
APIは孤立した島とは見なされません。APIは、他の開発者と機能を共有するための鍵であり、小さなビルディングブロックにカプセル化されています。
WunderHubを使用すると、これらのビルディングブロックを簡単に共有して、他の人がそれらの上に構築できるようになります。
技術比較＃
WunderGraphとHasuraはどちらも高性能言語の上に構築されており、HasuraはHaskellを使用して構築され、WunderGraphはGolangを使用して実装されています。
どちらの言語もコンパイルされているため、非常に高速です。また、どちらにも独自のスケジューラが付属しています。つまり、非同期ワークロードを多くのCPUスレッド間で多重化できるため、両方の言語を複数のCPU間で適切に拡張できます。たとえばNodeJSと比較すると、CPUを簡単に使い切ることができます。
TIOBEインデックスでは、Golangは1.21％で18位にランクされています。Haskellは0.24％で40位にランクされています。Haskellに精通している開発者よりもGo開発者を見つける方がはるかに簡単なはずです。Golangは、次のような多くの大規模プロジェクトでも使用されています...
- kubernetes
- cockroachdb
- etcd
- Docker
- 領事
- テラフォーム
- syncthing
WunderGraphがHasuraの優れた代替品であるのはなぜですか？＃
データベースから純粋なGraphQLAPIを公開するだけの場合は、Hasuraが適しています。
ただし、パブリックインターネット上のWebクライアントにAPIを公開することをすでに知っている場合は、GraphQLAPI自体を公開するだけでなく多くの作業を行う必要があります。APIを保護し、その上に、キャッシュ、承認、認証、安全なデータフェッチ、CSRF保護、ファイルアップロードなどを処理する独自のカスタムクライアントを構築する必要があります。
WunderGraphを使用すると、これらすべての問題を解決するための、よく維持されたフレームワークが得られます。これらすべての問題を自分で解決する場合は、誰がカスタムソリューションを維持し、誰がGraphQLクライアントの依存関係を更新し、誰が認証の実装が実際に安全であることを確認するかを考えてください。
このすべての作業は、集合的に維持できるフレームワークによって解決できます。フレームワークに抽象化できるのに、なぜ自分で維持しなければならないカスタムのプロプライエタリコードを使用するのですか？私たちは行動をカスタマイズするための多くの方法を提供しますが、その核心は個人によって維持されるべきではありません。
私たちの目標は、APIを統合して使用する方法を標準化し、ソリューションをオープンソースフレームワークとして利用できるようにすることです。このようにして、カスタム実装なしで、アプリケーションのほぼすべてのレイヤーでベストプラクティスと実証済みのパターンを使用できます。
WunderGraphを使い始める＃
ドキュメントを参照するか、クイックスタートを試してください。
あなたはまだ情報を集めていますか？WunderGraphが提供するすべての機能の詳細をご覧ください。APIメッシュとAPIセキュリティの詳細、およびWunderGraphをさまざまなペルソナに説明するセクションをご覧ください。
開発者の場合、開始する最も簡単な方法は、これをコピーして端末に貼り付けることです。
0 コメント:
コメントを投稿