발명 특허 공개--JSON 파일 + Http 헤더를 기반으로 다중 프로젝트, 다중 분기 및 다중 사용자 협업을 지원하는 Api Mock/프록시 도구

현재 단계에서 프론트 엔드와 백엔드 분리의 주류 개발 모드에서 프론트 엔드와 백엔드는 병렬 개발 방법을 채택하고 프론트 엔드 개발 프로세스는 일반적으로 공통적으로 합의된 인터페이스에 연결되어야 합니다. 형식 및 데이터.
여기에 이미지 설명 삽입
이 프로세스는 병렬 프로세스이므로 Api Mock 시뮬레이션 인터페이스의 반환이 필요합니다. 동시에 공동 디버깅 프로세스 중에 공동 디버깅을 위해 백엔드 서비스 주소를 수정 해야 합니다 .

팀의 21년 특허(특허 공개 번호: CN113630468A)의 일부이기도 한 팀의 솔루션이 이제 발표되었습니다.

과거 상태

프런트 엔드 개발 중에 두 서비스를 로컬에서 시작해야 합니다. 하나는 웹 정적 리소스를 지원하는 데 사용되고 다른 하나는 백그라운드 API 인터페이스를 시뮬레이트하는 데 사용됩니다.

그 중 정적 리소스 서비스에는 프록시 API 주소 기능이 포함되어 있으며, 이는 브라우저에서 보낸 백그라운드 데이터 인터페이스(일반 인터페이스 접두어는 동일한 특성을 가짐, 예를 들어 모두 "api/"로 시작) 및 전달하는 데 사용됩니다. API 인터페이스 서비스에서 백그라운드로 이동합니다. 그런 다음 대략 세 가지 사용 시나리오가 있습니다.

프런트 엔드 페이지를 개발할 때 프록시는 백그라운드 API 인터페이스를 시뮬레이트하는 로컬 서비스로 설정됩니다(아래 그림의 개발 환경 주소: http://localhost:8080).
백그라운드 인터페이스와의 공동 디버깅 시 프록시는 백그라운드 API 인터페이스 서비스(아래 그림의 백그라운드 환경 주소: http://192.168.0.100:8080)로 설정됩니다.
테스트 단계에서 프런트엔드 문제 해결 문제는 프록시가 테스트 환경의 API 인터페이스 서비스(아래 그림의 테스트 환경 주소: http://192.168.0.200:8080)로 설정될 수 있다는 것입니다.

문제 제기:

공동 디버깅은 일대다(한 프론트엔드 개발자가 여러 백엔드 개발자와 공동 디버깅을 수행함)일 수 있으며, 여러 백엔드 개발자는 여러 백엔드 환경의 주소가 있음을 의미합니다. 그런 다음 "Background A"와의 공동 디버깅이 완료된 후 에이전트를 "Background B"로 전환해야 합니다. 이러한 회전은 "Background A" 및 "Background B"와 교차 연결될 수도 있습니다. 이와 같이 현재 프런트 엔드 프로젝트 메커니즘에서 프록시 주소를 변경하는 단계는 다음과 같습니다.

1단계: 구성 파일에서 IP 주소 수정
2단계: 프런트 엔드 서비스 종료
3단계: 프런트 엔드 서비스 다시 시작(이 프로세스는 프런트 엔드 정적 리소스의 컴파일 프로세스를 실행하며 시작 속도는 프로젝트 규모에 따라 다름)

요컨대 프록시 주소를 변경하려면 관련 없는 많은 작업을 수행해야 하므로 개발 및 공동 디버깅의 효율성에 영향을 미칩니다.
프론트엔드 개발자는 종종 여러 프론트엔드 프로젝트에 산재해 있습니다. 예를 들어 다음 시나리오에서

여러 프로젝트가 병렬로 실행되고 있어 프록시 주소 포트 충돌 문제가 발생할 수 있으며 프록시 주소를 자주 수정한 다음 프런트 엔드 프로젝트를 다시 시작해야 합니다 .

구현 아이디어

목표 실현 : 전체 프런트 엔드 프로젝트를 다시 컴파일하지 않고 프록시 주소를 수정하십시오!
구현 방법 : 통합 프록시 서비스 fusion-mock을 추출하고 프론트 엔드 프로젝트의 프록시 주소를 fusion-mock의 주소로 통일하고 fusion-mock에서 대상 주소의 포워딩 전략을 구성하십시오!
여기에 이미지 설명 삽입
통합 프록시 플랫폼을 개발하고 모든 프로젝트 프록시 대상 주소가 이 플랫폼에 있습니다. 플랫폼은 해당 로고를 식별하여 다른 프로젝트와 다른 개발자를 식별한 다음 획득한 정보에 따라 전달 및 처리하여 매번 대상 주소를 수정하지 않고 통합 관리를 달성합니다(반복 구성 방지).
여기에 이미지 설명 삽입

Mock 데이터 저장 방식을 "DB"에서 "JSON 파일"로 개선하여
독립적인 DB 서비스를 구축할 필요 없이 JSON 파일 저장(각 인터페이스는 JSON 파일에 해당)합니다. 관련 JSON 파일의 관리는 간단하며 Git과 같은 관련 코드 웨어하우스에서 프로젝트와 함께 호스팅할 수 있습니다.
- 만들기 쉬움: 예 : /api/users/person/jerry=> /users/person디렉토리jerry.json , 관계가 명확하고 이해하기 쉽습니다!
- 편리한 관리: 모의 데이터는 현재 프로젝트에 저장되며 프로젝트 소스 코드와 함께 리소스 파일로 관리됩니다. 개발 프로세스와 협력하여 Mock 데이터를 잘 격리하고 재사용할 수 있습니다.
- 배포 불필요 : 독립적인 Mock 서비스 없음(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 사용자 정의 에이전트에 의해 구현된 다중 사용자 협업 모드에 의존합니다.

"변수"를 분리하는 방법은 위의 문제를 해결하는 핵심이며 전송 프로세스를 사용하여 "변수"를 전송하고 논리적 처리를 통합합니다.