BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース QCon PlusからAPIアーキテクチャトラックの総括

QCon PlusからAPIアーキテクチャトラックの総括

ブックマーク

原文(投稿日:2021/12/14)へのリンク

QCon PlusAPI アーキテクチャトラックが11月9日に開催され、API を設計、構築、保守するソフトウェアエンジニアとアーキテクトに関連するトピックについて話し合う6人のスピーカーとパネリストが参加した。これらは、拡張性や API ライフサイクルなどの幅広い概念から、APIを 構築するときに使用する最適なテクノロジーを決定するために REST、GraphQL、gRPC 間の対決にまで及んだ。

Square のソフトウェアエンジニアである Christi Schneider 氏は「Building with Extensibility」を発表した。これは、拡張可能なシステムを持つことの意味と、それが作り出す具体的な課題について深く掘り下げたものだ。Schneider 氏は、拡張性を設計プロセスの早い段階で考慮する必要と機能リストで「パブリックAPI」ボックスをチェックすることを単に望むことよりも多くの考慮が必要である理由についての良い例を示した。製品計画では、拡張性を基本的な機能と見なす必要がある。そうすることで、他の内部チーム、外部パートナ、およびサードパーティのいずれによっても、ソフトウェアを簡単に拡張できる。

しかし、彼女は、これは無料ではなく、真に拡張可能なシステムには追加の懸念があると警告した。たとえば、開発者サポートには公開ドキュメント、トレーニング、フォーラムなどが必要であり、カスタマサポートには、問題がコアシステムの一部であるかサードパーティの一部であるかを判断する機能が必要だ。正しく実装された場合、拡張可能なシステムは、開発者の満足度を高め、製品を成長させるための新しい機会を提供する。

API のライフサイクルは、ソフトウェアシステムの開発ライフサイクルのサブセットであり同様ではあるが、設計、開発、および保守にはより焦点を絞ったニーズがある。Postman のチーフエバンジェリストである Kin Lane 氏によると、API 標準と仕様を使用するとコミュニケーションが改善され、API ライフサイクルの管理が容易になるとのことだ。OpenAPI (以前の Swagger) は、http ベースの API を記述するための事実上の標準だ。AsyncAPI は OpenAPI をベースにイベント駆動型 API に関連する構文を追加している。どちらも JSON スキーマを使って API に出入りするメッセージ契約を記述する。

API 仕様の最も一般的なユースケースはドキュメントだ。しかし Lane 氏は、最新のイノベーションはさらに進んでいると述べている。仕様は人間と機械の両方で読み取りが可能なため、API ライフサイクルを改善するために新しいツールが絶えず作成されている。これは、API の契約の実装の基本的な検証テストから始まり、CI/CD パイプライン中に実行できる自動生成されたヘルス、セキュリティ、およびパフォーマンステストになる。Lane 氏は、将来の機能強化とツールにより、自動化と再現性が向上し、API ライフサイクルを適切に維持するために必要な労力が軽減されると考えている。

AsyncAPI Initiative の創設者である Fran Mendez 氏は、AsyncAPI を使用してイベント駆動型アプリを構築するコーディングデモを行った。彼は、ブラウザベースのエディターである AsyncAPI Studio のベータ版を使用していたが、AsyncAPI 仕様の YAML を手動で編集することもできる。契約はパブリッシュ (publish) チャネルとサブスクライブ (subscribe) チャネルを定義し、仕様を実装した Mosquitto MQTT サーバを構築した。この契約は、Web ソケットを使用してサーバと通信するフロントエンド Web アプリを生成するためにも使用された。最後の要素は、発生した特定のイベントに基づいて Slack にプッシュ通知を送信することだった。デモは AsyncAPI の現在の状態と、現在、存在するいくつかのツールの非常に迅速で簡潔な概要だった。Mendez 氏は、OpenAPI で起こったことに続いて、今後数年間でツールが成長し続けることを期待していた。

トラックのフィナーレは API Showdown だった。これは API 構築に使用すべきテクノロジーが本当に1つあるかどうかを決定する試みだ。3人のパネリストがそれぞれ特定のテクノロジースタックに関する専門知識を持っており、その機能に関する事実を提示するように求められた。Mulesoft の API 戦略のグローバルリーダである Matt McLarty 氏が REST を代表した。Netflix のソフトウェアエンジニアである Alex Borysov 氏は gRPC を代表した。そして Twitter のソフトウェアエンジニアである Michelle Garrett 氏は GraphQL を代表した。

背景、優れた実装シナリオ、不適切なシナリオ、および他のどのテクノロジーが優れたパートナになるかについて話し合った後、結果は「状況による」だった。各技術には明確な長所と短所があるが、銀の弾丸はない。

REST は参入障壁が最も低く、一般的に使用されているが、パフォーマンスや複雑なクエリには最適化されていない。GraphQL は、サーバやスキーマの記述などセットアップを得るためにいくらかの努力を必要とする。その結果、クライアントに多くの柔軟性が提供される。転送されるデータ量を大幅に減らすことができるが、誤って使用され、不要な処理が発生する可能性もある。gRPC の理想的なユースケースは、明確に定義されたデータをすばやく、好ましいのは2台のサーバ間で転送する必要がある場合だ。多くの場合 Protobuf を使用して定義される契約は、両側で理解する必要があるため、動的データモデルに簡単に適応することができない。

ペアリングする他のテクノロジーの1つを選択するように求められた場合でも、パネリストは両方のオプションについて説得力のある議論をした。すべてのアーキテクチャの決定と同様に、すべての人にとって正しい答えは1つではない。使用するテクノロジーを決定することは、トレードオフを分析し、ユースケースに対してネガティブな属性よりもポジティブな属性を持つ1つまたは複数のオプションを選択することだ。

2021年11月の QCon Plus の完全な総括が利用可能になった。次の QCon Plus はバーチャルで2022年5月10日〜20日に開催され、次の対面の QCon London は2022年4月4日〜6日に開催される。

作者について

この記事に星をつける

おすすめ度
スタイル

BT