未来#
私たちの計画は、2022年1月にオープンソースフレームワークをリリースすることです。私たちの長期的な目標は、より多くのバックエンドを接続し、より多くのフロントエンドテクノロジーと統合できるようにすることです。
バックエンド側では、SOAP、OData、gRPC、MongoDBのサポートを追加したいと思います。フロントエンド側では、Vue、Svelte、Angular、iOS、Android、Flutter、Java、Go、Python、Ruby、PHP、Typescript、Swift、Kotlin、C#のサポートを検討しています。
Dockerが存在する前にアプリケーションを共有した方法を覚えていますか?アプリケーションは、今日ほどポータブルではありませんでした。必要なすべてのパッケージを手動または自動でインストールする必要がありましたが、docker run
またはほど簡単ではありませんでしdocker build
た。
移植性とパッケージマネージャーがソフトウェア開発の方法をどのように変えたか#
Docker、さらにはOCI(Open Container Initiative)は、バンドルアプリケーションとそれらの配布方法を完全に変更しました。現在、Dockerレジストリからイメージをプルして、ローカルマシンまたはクラウドで実行できます。
同様に、npm、Composer、Mavenなどのパッケージマネージャーがない世界を想像できますか?jQueryのようなJavaScriptライブラリをCDNからHTMLに直接含める必要があった時期がありました。今日のソフトウェア開発方法は、パッケージマネージャー、バンドラー、ビルドツールに大きく依存しています。
これらのカテゴリのツールの両方に共通しているのは、ソフトウェアの開発方法を根本的に変えたことです。新しいワークフローが可能になり、開発者がコードを共同で共有しやすくなりました。
たとえば、Docker / OCIは、kubernetesへの道を開き、クラウドネイティブ環境でアプリケーションをデプロイする方法を標準化しました。
では、実際にAPIについて話したいときに、これら2つに言及する意味は何でしょうか。そうですね、APIの共有に関しては、まだ石器時代にいると思います。
APIコミュニティは、APIを保護および配布するためのAPIゲートウェイや開発者ポータルなどのツールを開発しましたが、API開発者とその消費者の開発者エクスペリエンスについて考えることを完全に忘れていました。
開発者ポータルにアクセスして、プロジェクトでAPIを使用することを決定するとどうなりますか?SDKをダウンロードするか、Swagger / OpenAPI仕様を使用して、手動統合プロセスを開始します。npm install
APIを使用して使用を開始する簡単な方法はありません。
一般的なプロジェクトは、単一のデータベースと単独で通信するだけではありません。おそらく、異なるチームやサードパーティの複数のAPIと統合する必要があります。マイクロサービスアーキテクチャには、多くの統合作業が必要です。さらに、APIを提供する強力なSaaSプロバイダーが多数あります。たとえば、電子メールの送信、ユーザーアカウントの管理などです。
これらすべてのサービスを統合することになると、開発者は多くの手作業を行う必要があります。SDKのラップ、フロントエンドのバックエンドの構築、シークレットの管理、認証の処理は、取り組むべき問題のほんの一部です。ほとんどの場合、この手動統合作業は、公開して共有できない独自のクローズドソースコードであるため、共有されません。これは、APIコンシューマーが同じまたは同様の作業を何度も繰り返し、時間とお金を浪費することを意味します。
API統合をと同じくらい簡単にしたいのですnpm install
。私たちの目標は、APIをDockerコンテナーと同じくらい移植可能にし、API開発者とそのコンシューマーがまったく新しいレベルでコラボレーションできるようにすることです。
APIを手動で統合することは、CDNからjQueryをインポートするようなものです。それを取り除きましょう!
解決策:APIを簡単に移植できるようにする方法#
Dockerと同様に、APIを移植可能にするための共通言語が必要です。さらに、API統合を実行するためのランタイムが必要です。
これら2つを取得したら、API開発者がAPIを「公開」し、コンシューマーがDockerやnpmと同様に、APIをプロジェクトに「プル」できるように、API統合を保存する場所が必要です。
GraphQL:API統合の共通言語#
言語については、GraphQLを使用することにしました。すべてのAPIを1つのGraphQLスキーマに結合することで、複数のAPIからのデータを一度に「クエリ」することができます。
その意味で、プロジェクトのすべてのAPI依存関係を表す「仮想グラフ」を作成しています。GraphQLは、フロントエンドに必要なデータを正確にフェッチするためのソリューションとして発明されました。
GraphQLには強力なコミュニティがあり、ユーザーから多くの愛を得ています。さらに、強力な型システムが付属しているため、統合用のTypeScriptインターフェイスなどを非常に簡単に生成できます。
WunderGraph:API統合のランタイム#
昨年私たちが行ったことは、API統合のランタイムを構築することです。WunderGraphを使用すると、さまざまなサービスのAPIを1つのGraphQLスキーマに簡単に組み合わせることができます。私たちのランタイム/エンジンは、それらを共通の形式に組み合わせることができ、ほとんどすべてのサービスに対してGraphQL操作を実行できます。
これまでのところ、次のバックエンドをサポートしています。
- REST(OpenAPI / Swagger)
- GraphQL
- アポロ連盟
- PostgreSQL
- MySQL
- SQLite
- SQLサーバー
これらのいずれかを「イントロスペクト」して、1つのコマンドで「ポータブル」なWunderGraph形式に変換できます。
上記のバックエンドに加えて、次のフロントエンドもサポートしています。
- REST(-ish)API
- Postmanコレクション
- 生成されたSDK
- TypeScript
- React
- リアクトネイティブ
「フロントエンド」について話すときは、API統合を利用する方法について話します。WunderGraphは、APIをGraphQLスキーマに結合して、それを1日と呼ぶだけではありません。さらに一歩進んで、APIを呼び出すだけでなく、認証と承認、キャッシュ、セキュリティなどを処理できる、API用の完全なすぐに使用できるSDKを生成します。
WunderHub:API統合を保存および共有する場所#
ソリューションの最後のコンポーネントはWunderHubです。これは、API統合を保存および共有できる場所です。Docker Hubまたはnpmと同様に、APIの説明を公開してコミュニティと共有できます。
それらをすべての人と公に共有することも、自分の組織の人だけなど、グループだけにアクセスを制限することもできます。
共通言語であるランタイムとハブの3つのコンポーネントを使用して、WunderGraphとハブを使用してAPIを統合するフローを見てみましょう。
それはどのように機能しますか?#
WunderHubを使用してAPIを共有する#
最初のステップは、共有するAPIをイントロスペクトし、それをポータブルWunderGraph形式に変換することです。これは、WunderGraphのTypeScriptSDKを使用して実行できます。次に例を示します。
SDKを使用すると、1つ以上のAPIをイントロスペクトして、それらを組み合わせて公開できます。npmの動作と同様に、APIを組織に公開し、さまざまな方法を使用してAPIを記述できます。
公開する準備ができたら、次のコマンドを実行します。
ハブで公開されているAPIの統合#
それでは、WunderGraphを使用してAPIを統合するフローについて説明しましょう。
まず、新しいプロジェクトを開始しましょう。
次に、2つのAPIをワークスペースに追加しましょう。
追加されたAPI依存関係は、自動的にダウンロードおよびインストールされます。プロジェクトのすべてのAPI依存関係はwundergraph.manifest.json
ファイルに保存されます。
APIをワークスペースに追加したら、WunderGraphSDKを使用してそれらをWunderGraphAPIに追加できます。
ご覧のとおり、生成された「統合」ファイルから両方のAPIをインスタンス化しています。あなたの注意を喚起するかもしれない1つの小さな詳細、apiNamespace
パラメータがあります。
WunderGraphは、すべてのAPIを単一のGraphQLスキーマに結合します。異なるチームまたはベンダーのAPIを同じGraphQLスキーマに組み合わせると、名前の衝突が発生する可能性が非常に高くなり、スキーマが破損します。さまざまなAPIを独自の名前空間に配置することで、手動で構成しなくてもこれらの問題を回避できます。
最後のステップとして、新しく作成したAPIと対話するための操作を定義する必要があります。
このクエリは、SpaceXとCountriesAPIの両方からデータを取得します。また、両方のAPIのルートレベルフィールドのプレフィックスがAPI名前空間であることがわかります。
これで、WunderGraphアプリケーションを起動して使用を開始する準備が整いました。
そして最後に、それを照会しましょう!
この例では、curlを使用して生成されたREST(-ish)APIをクエリしていますが、さらに高度な方法で、生成されたTypeScriptクライアント、生成されたPostmanコレクションなどを使用することもできます...
まとめ#
SDKを使用してGraphQLAPIをイントロスペクトし、公開用に準備してから、ハブにプッシュしました。
次に、APIコンシューマーとして、プロジェクトに2つのAPIを追加し、それらをapi名前空間でインスタンス化しました。最後に、オペレーションを定義し、curlを使用して新しく作成したAPI統合と対話しました。
これは簡単な例のように見えるかもしれませんが、どれだけの時間を節約できるかが明確になっていることを願っています。
このフローを使用しない場合、世界はどのように見えますか?#
前に述べたように、API統合はまだ石器時代にあると考えているので、WunderGraphフローと、開発者がWunderGraphなしで同じ問題を保存する方法を比較してみましょう。
- まず、REST APIを構築するためのテクノロジー、言語、フレームワークを決定する必要があります
- 次に、APIに新しいエンドポイントを追加します
- graphql-code-generatorなどのツールを使用して、両方のAPIのタイプセーフなAPIクライアントを生成します
- 生成されたクライアントを使用して両方のAPIを照会し、RESTエンドポイントを実装します
- RESTエンドポイントのJSONスキーマを定義する
- 認証および承認レイヤーをRESTエンドポイントに追加します(これはWunderGraphに含まれているバッテリーです)
- キャッシングミドルウェアを追加します(これはWunderGraphに含まれているバッテリーです)
- curlを使用してRESTエンドポイントをクエリします
WunderGraphはAPIを統合するだけではないため、リストを簡単に長くすることができます。機能をご覧ください。ツールスイートは、認証から承認、役割ベースのアクセス制御、モック、JSONスキーマ検証、自動ETag、S3ファイルのアップロードなど、APIに関するすべての問題を解決するのに役立ちます。
さらに、別のAPIを追加する必要がある場合、またはAPIの1つを更新する必要がある場合にどうなるか想像してみてください。WunderGraphとハブを使用すると、数分でほとんど自動化されます。あなたはそのような退屈な仕事のためにあなたの時間を本当に無駄にするべきではありません。
WunderHubクローズドベータ版の発表#
WunderGraph、ランタイム/エンジンは非常に安定しており、本番環境に対応しています。WunderGraphファンのコミュニティと協力して、過去数か月で成熟させることができました。
フレームワークを制限なしで一般に公開する前に、最終ステップに向けて前進する時が来ました。
この最後のステップを簡単にするために、コミュニティの皆さんからのフィードバックが必要です。
クローズドベータ版に参加して、WunderGraphフレームワークとハブの両方の開発者エクスペリエンスを最適化するのを手伝ってください。
興味のある方は、https://hub.wundergraph.comをご覧になり、プライベートベータ版にサインアップしてください。さらに、Discordに参加して、そこでベータ版への参加を依頼することもできます。
ハブとフレームワークがAPIの操作体験を向上させるのに役立つと思われる場合は、ぜひご意見をお聞かせください。
未来#
私たちの計画は、2022年1月にオープンソースフレームワークをリリースすることです。私たちの長期的な目標は、より多くのバックエンドを接続し、より多くのフロントエンドテクノロジーと統合できるようにすることです。
バックエンド側では、SOAP、OData、gRPC、MongoDBのサポートを追加したいと思います。フロントエンド側では、Vue、Svelte、Angular、iOS、Android、Flutter、Java、Go、Python、Ruby、PHP、Typescript、Swift、Kotlin、C#のサポートを検討しています。
私たちのビジョンは、バックエンドとフロントエンドの両方にとらわれずに、APIに関するすべての問題を解決するためのメタフレームワークになることです。バックエンドまたはフロントエンドのテクノロジーを使用できるはずです。API統合やセキュリティなどの重労働を処理しています。
次に読むべきこと
これはあなたが面白いと思う記事の厳選されたリストです。
- WunderHubの発表では、WunderHubがAPIでの共有とコラボレーションの方法をどのように変えるかについて話します。npmパッケージのようなAPIを共有することができます。
- API統合の自動化がビジネスにどのように役立つか は、API統合の自動化のビジネス上の利点について詳しく知りたい経営幹部に捧げられています。
- もう1つの興味深いトピックは 、単一のGraphQL操作を使用するだけで、スキーマスティッチングやフェデレーションなしでAPIを結合することです。
- 最も一般的なGraphQLセキュリティの脆弱性に関心のある方は 、それらについて、およびWunderGraphがそれらを回避するのにどのように役立つかを読むことをお勧めします。
- 古典的な投稿ですが、それでも関連性があるのは 、GraphQLがインターネット上で公開されることを意図していないことです。それは物議を醸すトピックであり、多くの人がそれを誤解しています。しかし、考えてみてください。GraphQL仕様でHTTPが一度も言及されていないのはなぜですか?
- GraphQLを使用する際の非常に一般的な問題の1つは、型を何度も宣言する問題である二重宣言問題です。この投稿では、二重宣言よりもさらに複雑であり、それをどのように解決できるかについて説明しています。
- GraphQLRESTとHTTP/2の融合は 非常に長い投稿であり、おそらくブログ投稿には長すぎます。しかし、WunderGraphの作成の背後にある動機について深く掘り下げることに興味がある場合は、これがあなたのための投稿です。
著者について
Jens Neuse、CEO兼創設者@ WunderGraph
Jensは、iOSおよびAndroid向けのネイティブアプリの構築、Xamarin、React Native、Flutterを使用したハイブリッドアプリの構築、PHP、Java、Goを使用したバックエンドの開発の経験があります。彼は開発からアーキテクチャに至るまでの役割を果たしており、ますます大規模なエンジニアリングチームを率いています。
彼のキャリア全体を通して、APIの操作は非常に複雑で反復的であり、さらに多くの標準化と自動化が必要であることに気づきました。そのため、彼はWunderGraphを開始し、APIの使用とAPIを介したコラボレーションを容易にしました。
彼は、将来のビジネスは、APIを介して接続されたコラボレーションシステムの上に構築されると信じています。この目標を達成するには、APIの使用、探索、共有、およびAPIとのコラボレーションを容易にすることが重要です。
Jensをフォローして接続し、アイデアを交換したり、彼の考えのフィードに参加したりします。
0 コメント:
コメントを投稿