発明特許公開 -- JSON ファイル + Http ヘッダーに基づいてマルチプロジェクト、マルチブランチ、マルチパーソンのコラボレーションをサポートする API モック/プロキシツール

現段階では、フロントエンドとバックエンドの分離という主流の開発モードでは、フロントエンドとバックエンドは並行開発方式を採用しており、フロントエンド開発プロセスは通常、共通に合意されたインターフェースに接続する必要があります。フォーマットとデータ。
ここに画像の説明を挿入
このプロセスは並列プロセスであるため、Api Mock シミュレーションインターフェイスの復帰が必要になります。同時に、共同デバッグプロセス中に、共同デバッグ用のバックエンドサービスアドレスを変更する必要もあります。

このチームのソリューションが発表されました。これはチームの 21 年間の特許 (特許公開番号: CN113630468A) の一部でもあります。

歴史的状況

フロントエンド開発中は、2 つのサービスをローカルで開始する必要があります。1 つは Web 静的リソースをサポートするために使用され、もう 1 つはバックグラウンド API インターフェイスをシミュレートするために使用されます。

このうち、静的リソースサービスにはプロキシ API アドレス関数が含まれており、これはブラウザーによって送信されるバックグラウンドデータインターフェイス (一般的なインターフェイスのプレフィックスは同じ特性を持ちます。たとえば、すべて "api/" で始まります) を転送するために使用されます。 API インターフェースのサービスのバックグラウンドに移動します。次に、使用シナリオは大まかに 3 つあります。

フロントエンドページを開発する場合、プロキシはバックグラウンド API インターフェイスをシミュレートするローカルサービス (下図の開発環境アドレス: http://localhost:8080) に設定されます。
バックグラウンドインターフェースと共同デバッグする場合、プロキシはバックグラウンド API インターフェースサービス (下図のバックグラウンド環境アドレス: http://192.168.0.100:8080) に設定されます。
テスト段階でのフロントエンドのトラブルシューティングの問題は、プロキシがテスト環境の API インターフェイスサービス (下図のテスト環境のアドレス: http://192.168.0.200:8080) に設定される可能性があることです。

問題が発生します:

共同デバッグは 1 対多 (1 人のフロントエンド開発者が複数のバックエンド開発者と共同デバッグを行う) の場合があり、複数のバックエンド開発者とは、複数のバックエンド環境のアドレスが存在することを意味します。次に、「バックグラウンド A」との結合デバッグが完了した後、エージェントを「バックグラウンド B」に切り替える必要があります。このようなローテーションは、「バックグラウンド A」と「バックグラウンド B」とクロス結合することもできます。このように、現在のフロントエンドプロジェクトのメカニズムでは、プロキシアドレスを変更する手順は次のとおりです。

ステップ 1: 構成ファイル内の IP アドレスを変更します。
ステップ 2: フロントエンドサービスを強制終了します。
ステップ 3: フロントエンドサービスを再起動します (このプロセスでは、フロントエンド静的リソースのコンパイルプロセスが実行され、起動速度が低下します)。プロジェクトの規模によって異なります）

つまり、プロキシアドレスを変更するには、多くの無関係な作業を行う必要があり、開発や共同デバッグの効率に影響を与えます。
フロントエンド開発者は、複数のフロントエンドプロジェクトに分散していることがよくあります。たとえば、次のシナリオでは、

複数のプロジェクトが並行して実行されているため、プロキシアドレスポートの競合の問題が発生する可能性があり、プロキシアドレスを頻繁に変更してから、フロントエンドプロジェクトを再起動する必要もあります。

実装のアイデア

フロントエンドプロジェクト全体を再コンパイルせずにプロキシアドレスを変更するという目標を実現してください。
実装方法: 統合プロキシサービス fusion-mock を抽出し、フロントエンドプロジェクトのプロキシアドレスを fusion-mock のアドレスとして統合し、ターゲットアドレスの転送戦略を fusion-mock で設定します。
ここに画像の説明を挿入
統合プロキシプラットフォームを開発すると、すべてのプロジェクトプロキシターゲットアドレスがこのプラットフォーム上にあります。プラットフォームは、対応するロゴを識別することで異なるプロジェクトと異なる開発者を識別し、取得した情報に応じて転送および処理することで、ターゲットアドレスを毎回変更することなく一元管理を実現します（重複構築を回避します）。
ここに画像の説明を挿入

モックデータの保存方法を「DB」から「JSON ファイル」に改良し、
JSON ファイルストレージ (各インターフェースが JSON ファイルに対応) を使用することで、独立した DB サービスを構築する必要がなくなりました。関連する JSON ファイルの管理は簡単で、Git などの関連コードウェアハウスでプロジェクトとともにホストできます。
- 作成は簡単です: =>ディレクトリなど、/api/users/person/jerry/users/personjerry.json関係が明確でわかりやすいです。
- 便利な管理: モックデータは現在のプロジェクトに保存され、プロジェクトのソースコードとともにリソースファイルとして管理されます。開発プロセスと連携して、モックデータを適切に分離して再利用できます。
- デプロイ不要: 独立したモックサービス (DB サービスなどを含む) なし

Http ヘッダーを使用して関連情報を特定し、プロキシアドレスを統一する

const mockPath = join(__dirname, 'mock')

devServer: {
      
      
  host: '0.0.0.0',
  proxy: {
      
      
    '/api': {
      
      
      // fusion-mock地址
      target: 'http://localhost:18080',
      /*
      * 'mock-server': '项目标识',
      * 'mock-path':'mockdata路径'
      */
      headers: {
      
       'mock-server': 'am-fe', 'mock-path': mockPath },
      changeOrigin: true
    },
    '^/websocket': {
      
      
      target: 'ws://localhost:18080',
      headers: {
      
       'mock-server': 'am-fe' },
      changeOrigin: true,
      ws: true
    }
  }
}

すべての開発者は、Fusion Mock のサービスアドレス (http://domain:port など) を均一に構成でき、ヘッダーのフィールドを通じてさまざまなプロジェクトが関連付けられます。接続アドレスの切り替えは再構築する必要はなく、ツール上で動的に変更するだけで済みます。
ここに画像の説明を挿入

同一プロジェクト、複数人コラボレーションモード
同じプロジェクトのオンライン共同開発では、複数の開発者が異なるターゲットサーバーに接続する必要があり、異なる開発者を識別して差分転送を実行するために Http Referer を識別できます。
Referer: http://localhost:8080/api/auth/time?xxx

具体的な実装

ここに画像の説明を挿入

モックメカニズムは、API パスとストレージ JSON ファイルパスと一致するようにプロジェクトディレクトリに実装する必要があります。API パスの最後のレベルは JSON ファイル名で、前のレベルはフォルダーディレクトリです。例:/users/person/jerry対応する JSON ファイルは次のとおりです: プロジェクトパス/mocks/users/person/jerry.json

モック/server.js

app.use(async ctx => {
      
      
  let url = ctx.request.url
  // /api/users/person/jerry => /mocks/users/person/jerry.json
  let filePath = path.join(__dirname, ctx.request.path.replace('/api/', '') + '.json')
  let data
  if (fs.existsSync(filePath)) {
      
      
    try {
      
      
      data = jsonfile.readFileSync(filePath)
    } catch (err) {
      
      
      console.error('request: ' + url + ' fail!!!')
    }
  } else {
      
      
    console.warn('request: ' + url + ' not exist!!!!')
  }
  ctx.set('Content-Type', 'application/json')
  ctx.body = data
})

統合されたプロキシツールを実現し、すべてのフロントエンドプロジェクトがこのツールアドレスにリクエストを転送し、ツールが均一に配布されます (設定されたアドレスに従って 2 次転送が実行されます)。詳細は以下のとおりです。

フロントエンドは独自のロゴをヘッダーに反映します (ヘッダーへの反映はプロジェクトに干渉しません)

proxy: {
        
        
	'/api': {
        
        
  	// fusion-mock地址
		target: 'http://localhost:18080',
 		/*
  	 * 'mock-server': '项目标识',
  	 * 'mock-path':'mockdata路径'
  	 */
  	headers: {
        
         'mock-server': 'am-fe', 'mock-path': path.join(__dirname, 'mock') },
		changeOrigin: true
  }
}

統合されたプロキシツールは、ヘッダー内の ID を識別し、ID に応じて関連するプロキシ設定と読み取りを実行します。
統合されたプロキシツールは、リファラー内のキーワードに従って、一致するプロキシ転送を実行できます。

統合プロキシツールは、プロジェクトにプロキシが設定されていないことを読み取ると、デフォルトでヘッダーに含まれる絶対モックパスを使用して、プロジェクト内の JSON ファイルを読み取ります。

 // mockServer 应该是被代理项目的名称，也是mock-assets中的文件夹名称
 const mockServer = ctx.header['mock-server'] as string
 const mockPath = ctx.header['mock-path'] as string
 
 // 如果匹配到了 referer 的配置或者开启了 proxy
 if (isMatcheMReferer || isttpRemoteProxy) {
        
        
   // 转发到目标 url
   await await proxyBranch(ctx, targetUrl)
   // return 结束函数运行
   return
 }
 
 // 拆解path路径 找到对应的文件，ctx.mockpath 为 mock 地址的绝对路径
 const filePath = join(_mockPath, ctx.path.replace(searchValue, '') + '.json')
 // read. 读取文件内容
 const content = await promises.readFile(filePath, 'utf8')
 ctx.body = JSON.parse(content)
 ```

要約する

JSON ファイルパスが API パスと一致するストレージフォーム (シンプルかつ効率的)。
HTTP ヘッダーに依存して ID を識別し、動的プロキシを実行します。
Http Referer カスタムエージェントによって実装された複数人コラボレーションモードに依存します。

上記問題を解決するには「変数」をいかに分離するかが核心であり、送信プロセスを利用して「変数」を転送し、論理的な処理を統一します。