원형 확인과 번역의 흐름을 유지하는 API의 전환

[vBET]

난 당신의 설명과 요점을 이해합니다. 이제 우리는 그것이 기술적으로 작동 가정해 방법을 찾아야 해요.

여기서 볼 수 한 문제는 우리가 이미 이전에 도달 어디에 그 이후에 가능한 한계가있다는 인식 방법입니다.

우리가 단순히 각 시간 요청할 수 있습니다 기본 공급자 및 다음 중 하나를 누른 다음 이동. 이 페이지 번역을 필요로 하는 각 요청에 대해 기본 공급자 (그래서 vBET 자세한 Api 지원 됩니다 때 여러 번 실패 한 호출 될 수 있습니다) 다음 다음 중 하나를 실패 한 호출을 만든 것 때문에 성능-비용을 것입니다.

다른 솔루션을 선호하는 공급자가 사용할 수없는 정보를 저장하고 다음 단계로 직접 이동하는 것입니다. 지역 변수를 확인하면 외부 서버에서 응답을 기다리는 것보다 훨씬 빠르게 때문에 이것은 훨씬 빠를 것입니다. 이번 우리는 다른 문제를 가지고 - 우리가 선호하는 공급자가 사용할 수있을 때 몰라요. 우리는 물론 그것을 확인하는 시간 / 하루에 한 번 예를 들어, 간단한 (단편) 번역 부탁 것이 몇 가지 예약된 작업을 만들 수 있습니다. 그래서이 전략에 우리는 기본적으로 이러한 작업을 작업하기로 결정 얼마나 자주해야합니다. 물론 우리는 공급자가 사용할 수없는 것으로 표시된 경우에만 그것을 확인합니다.
우리는 사용할 수로 공급자 표시 또한 경우 - 우리 모두 공급자가 제공하지 않고있다는 것도 알고있다면 무엇을 할 - 번역 업체의 일시 부족에 대한 추가 정보없이 최종 사용자에 대한 몇 가지 정보를 추가하거나 원본으로 캐시와 나머지에서 무엇 번역 .

그것이 할 수 방법에 상관없이, Google은 취급하지 않겠다고 한번 API (V1 또는 V2가 구성에 따라) - 구글 V1은 곧 폐쇄되기 때문에 그것을 분할 아무 의미가 없습니다.

다른 점은 공급자 큐 각 언어 쌍을 별도로 구성할 수 있도록 하는 것입니다. 이 순간 Vbet는 이미 각 언어 쌍의 번역 공급자를 구성할 수 있습니다. 난 우리가 하나의 값에서 쉼표로 구분 된 값 (CSV)에 그것을 변경할 수 있습니다. 우리가 각 언어 쌍에 대해 알고 것입니다이 이런식으로 어떤 공급자 지원이 번역 하 고 환경 설정 순서 (CSV 목록에 그냥 순서)을 무엇입니까.

참고 : 이 어쨌든 몇 가지 성능 영향을 미칠 것입니다. 대신에 번역 하나의 개체를 만드는 우리는 이러한 개체의 배열 및 추가 포장 개체 (코드와 적은 버그 발생하기 쉬운의 다른 부분을 위해 투명하게)를 작성해야합니다. 물론 우리는 우리가이 순간에 사용할 수 없습니다 알아 제공을위한 개체를 만들 수 없습니다.
이것에 대한 솔루션 성능 향상을 위해 다시 구성하고 공급자 대기열 제거됩니다 - 그게 바로 지금처럼 - 언어 쌍 당 하나의 공급자를.
이것은 아직 몇 가지 추가적인 로직 및 메모리 소비 성능 비용이 있지만, 안됩니다.

솔루션 선호하는 말씀해주십시오.