2022年7月16日土曜日

WunderHubの発表:npmパッケージのようにAPIを共有する。

https://wundergraph-com.translate.goog/blog/announcing_wunderhub_share_apis_like_they_were_npm_packages?_x_tr_sl=en&_x_tr_tl=ja&_x_tr_hl=ja&_x_tr_pto=sc

未来

私たちの計画は、2022年1月にオープンソースフレームワークをリリースすることです。私たちの長期的な目標は、より多くのバックエンドを接続し、より多くのフロントエンドテクノロジーと統合できるようにすることです。

バックエンド側では、SOAP、OData、gRPC、MongoDBのサポートを追加したいと思います。フロントエンド側では、Vue、Svelte、Angular、iOS、Android、Flutter、Java、Go、Python、Ruby、PHP、Typescript、Swift、Kotlin、C#のサポートを検討しています。

公開日: 2022-01-02
Jens Neuse、CEO兼創設者@ WunderGraph

Dockerが存在する前にアプリケーションを共有した方法を覚えていますか?アプリケーションは、今日ほどポータブルではありませんでした。必要なすべてのパッケージを手動または自動でインストールする必要がありましたが、docker runまたはほど簡単ではありませんでしdocker buildた。

せっかちな場合は、すぐにWunderHubWebサイトをチェックしてください。ただし、最初に発表を読んで、WunderGraphとハブの構築の背後にある動機を理解することをお勧めします。

移植性とパッケージマネージャーがソフトウェア開発の方法をどのように変えたか

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 installAPIを使用して使用を開始する簡単な方法はありません。

一般的なプロジェクトは、単一のデータベースと単独で通信するだけではありません。おそらく、異なるチームやサードパーティの複数の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がAPI統合の標準言語になると信じています。

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を使用して実行できます。次に例を示します。

                  
//まず、APIをイントロスペクトします
const = イントロスペクト graphql {
url "https://countries.trevorblades.com/"
} ;
//次に、ハブに公開するための準備をします
configurePublishWunderGraphAPI {
組織 「wundergraph」
apiName "国"
タイトル 「Trevor'sCountries」
markdownDescriptionFile "countries.md"
パブリック true
キーワード [ "国" "trevor" "trevorblades" ]
apis [
]
} ;

SDKを使用すると、1つ以上のAPIをイントロスペクトして、それらを組み合わせて公開できます。npmの動作と同様に、APIを組織に公開し、さまざまな方法を使用してAPIを記述できます。

公開する準備ができたら、次のコマンドを実行します。

                  
$ wundergraphpublishgenerated / wundergraph.countries.api.json

ハブで公開されているAPIの統合

それでは、WunderGraphを使用してAPIを統合するフローについて説明しましょう。

まず、新しいプロジェクトを開始しましょう。

                  
$ wundergraph init
$ cd .wundergraph
$

次に、2つのAPIをワークスペースに追加しましょう。

                  
$wunderctl統合は wundergraph/countrys wundergraph/spacexを追加します

追加されたAPI依存関係は、自動的にダウンロードおよびインストールされます。プロジェクトのすべてのAPI依存関係はwundergraph.manifest.jsonファイルに保存されます。

                  
{{
「依存関係」 [
"wundergraph / spacex"
「wundergraph/countries」
]
}

APIをワークスペースに追加したら、WunderGraphSDKを使用してそれらをWunderGraphAPIに追加できます。

                  
インポート {
アプリケーション
configureWunderGraphApplication
cors
テンプレート
} from "@ wundergraph / sdk" ;
"./wundergraph.hooks"からwunderGraphHooksをインポートします;
"./wundergraph.operations"から操作をインポートします;
import { integrations } from "./generated/wundergraph.integrations" ;
constspacex =統合_ wundergraph スペースX {
apiNamespace "spacex"
} ;
const = 統合 wundergraph {
apiNamespace "国"
} ;
const myApplication = new Application {
名前 「アプリ」
apis [
スペースX
]
} ;

ご覧のとおり、生成された「統合」ファイルから両方のAPIをインスタンス化しています。あなたの注意を喚起するかもしれない1つの小さな詳細、apiNamespaceパラメータがあります。

WunderGraphは、すべてのAPIを単一のGraphQLスキーマに結合します。異なるチームまたはベンダーのAPIを同じGraphQLスキーマに組み合わせると、名前の衝突が発生する可能性が非常に高くなり、スキーマが破損します。さまざまなAPIを独自の名前空間に配置することで、手動で構成しなくてもこれらの問題を回避できます。

最後のステップとして、新しく作成したAPIと対話するための操作を定義する必要があります。

                  
クエリ DragonsAndContries {
ドラゴン spacex_dragons {
名前
アクティブ
}
countries_countries {
コード
名前
資本
}
}

このクエリは、SpaceXとCountriesAPIの両方からデータを取得します。また、両方のAPIのルートレベルフィールドのプレフィックスがAPI名前空間であることがわかります。

これで、WunderGraphアプリケーションを起動して使用を開始する準備が整いました。

                  
#.wundergraphディレクトリにcdして、次を実行します。
$ wunderctl up --debug

そして最後に、それを照会しましょう!

                  
$ curl http:// localhost:9991 / api / main / operations / DragonsAndContries

この例では、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統合やセキュリティなどの重労働を処理しています。

次に読むべきこと

これはあなたが面白いと思う記事の厳選されたリストです。

著者について
イェンス・ヌース

Jens Neuse、CEO兼創設者@ WunderGraph

Jensは、iOSおよびAndroid向けのネイティブアプリの構築、Xamarin、React Native、Flutterを使用したハイブリッドアプリの構築、PHP、Java、Goを使用したバックエンドの開発の経験があります。彼は開発からアーキテクチャに至るまでの役割を果たしており、ますます大規模なエンジニアリングチームを率いています。

彼のキャリア全体を通して、APIの操作は非常に複雑で反復的であり、さらに多くの標準化と自動化が必要であることに気づきました。そのため、彼はWunderGraphを開始し、APIの使用とAPIを介したコラボレーションを容易にしました。

彼は、将来のビジネスは、APIを介して接続されたコラボレーションシステムの上に構築されると信じています。この目標を達成するには、APIの使用、探索、共有、およびAPIとのコラボレーションを容易にすることが重要です。

Jensをフォローして接続し、アイデアを交換したり、彼の考えのフィードに参加したりします。

コメントコメント

0 コメント:

コメントを投稿