メインコンテンツへスキップ
  1. 投稿/

OpenAPIファースト開発:フロントエンドとバックエンドの並行作業

· loading · loading ·
ジャレッド リンスキー
著者
ジャレッド リンスキー
韓国に住むキウイ
OpenApi - この記事は連載の一部です
パート 1: この記事

フロントエンドがバックエンドのAPI構築を待っていると、遅延が生じます。OpenAPIファーストアプローチはこれを解決します。APIコントラクトを事前に定義し、モックサーバーを立ち上げ、両チームが同時に作業できるようにします。

従来のアプローチ
#

従来、バックエンドチームはAPIの設計と実装から始めます。APIエンドポイントが機能すると、フロントエンドチームはそれらを統合し始めます。この連続的な方法論は、フロントエンド開発者がバックエンドの準備が整うのを待たなければならないため、しばしば遅延につながります。

同期アプローチ
#

同期アプローチでは、両方のチームがほぼ同時に作業を開始します。このアプローチの基盤はOpenAPIスキーマです。コードが書かれる前に、APIの構造、エンドポイント、期待される応答が定義されます。これにより、フロントエンドとバックエンドの間に明確な契約が提供され、両方が協調して作業できるようになります。

利点
#

  1. 明確性とビジョン: 事前のAPIスキーマは、機能の要件とその機能方法について明確な理解を確立します。
  2. 並行開発: バックエンドがまだ開発段階にある間に、フロントエンド開発者はUI/UXの作業を開始できます。
  3. より速い反復: 両チームが従うべき契約を持っているため、変更をより迅速かつスムーズに組み込むことができます。
  4. 改善されたテスト: OpenAPIスキーマに基づいてモックサーバーを設定でき、バックエンドが準備される前でもフロントエンドテストが可能になります。

プロセス
#

  1. 要件収集: どのプロジェクトでも同様に、機能の要件と目的を理解することから始めます。
  2. スキーマ設計: OpenAPI仕様を使用して、すべてのエンドポイント、リクエスト-レスポンスモデル、認証方法、エラーコードを定義します。
  3. レビューとフィードバック: フロントエンドとバックエンドの両方のチームがスキーマをレビューし、ニーズに応え、潜在的な問題が解決されるようにする必要があります。
  4. モックサーバー: SwaggerやPostmanなどのツールは、OpenAPIスキーマからモックサーバーを生成できます。フロントエンド開発者は、これらのサーバーを使用してテストと統合を行うことができます。
  5. バックエンド開発: 明確なロードマップを手に、バックエンド開発者はAPIエンドポイントの実装を開始できます。
  6. 統合とテスト: バックエンドエンドポイントが利用可能になると、モックサーバーを置き換えることができます。継続的なテストにより、契約が遵守され、統合の問題が減少します。
  7. フィードバックループ: チーム間の定期的なコミュニケーションにより、プロセスの早い段階で潜在的な改善や問題を特定できます。

潜在的な課題
#

このアプローチは多くの利点を提供しますが、課題がないわけではありません:

  • 事前投資: 広範なOpenAPIスキーマを事前に作成することは時間がかかる可能性があります。
  • 変更管理: 要件の変更は、スキーマの改訂を必要とする可能性があり、フロントエンドとバックエンドの両方に影響を与える可能性があります。
  • オーバーヘッド: 両チームは、OpenAPIと使用されるツールに精通している必要があります。

結論
#

OpenAPIスキーマの設計への事前投資は、すぐに元が取れます。両チームが明確なコントラクトを得て、フロントエンドはモックデータですぐに作業を開始でき、統合の問題が早期に浮き彫りになります。オーバーヘッドは節約できる時間と比べれば最小限です。

OpenApi - この記事は連載の一部です
パート 1: この記事