Цыркуляр праверкі і пераключэнне API, каб захаваць паток перакладаў

[vBET]

Я разумею ваша апісанне і паставіць кропку. Цяпер мы павінны даведацца, як гэта мяркуюць, каб працаваць у тэхнічным плане.

Адзін з пытанняў, я бачу, вось як мы прызнаем, што ў нас ужо ёсць межы даступныя пасля тых, дзе дасягнута раней.

Мы можам проста кожны раз прасіць пераважнага пастаўшчыка, а затым перайсці да наступнага. Гэта будзе каштаваць выкананне - таму што для кожнага запыту старонкі, якія патрабуюць перакладу, мы зрабілі няўдалую выклік пераважнага пастаўшчыка, то да наступнага (таму ён можа быць некалькі няўдалых званкоў, калі Б. прадпрыемства будзе аказваць падтрымку больш API).

Іншае рашэнне было б для захоўвання інфармацыі, пераважнага пастаўшчыка не даступная і адразу перайсці да наступнага. Гэта было б значна хутчэй, таму што праверка лакальных зменных нашмат хутчэй, чым чакаць адказу ад вонкавага сервера. На гэты раз у нас ёсць іншыя праблемы - мы не ведаем, калі пераважнага пастаўшчыка маецца. Можна, вядома, зрабіў некаторыя запланаваныя задачы, якая б звярнуцца за просты (кароткі) пераклад напрыклад, раз у гадзіну / дзень, каб праверыць яго. Так што ў гэтай стратэгіі мы павінны вырашыць, як часта па змаўчанні, такой задачы, мяркуюць, каб працаваць. Вядома, мы б праверыць яго толькі тады, калі некаторыя пастаўшчык пазначаецца як не даступныя.
Акрамя таго, калі мы адзначаем правайдэраў як недаступныя - што рабіць, калі мы ведаем, што ўсе правайдэры не даступны - дадаць некаторую інфармацыю для канчатковага карыстальніка, ці проста перавесці тое, што знаходзіцца ў кэшы, а астатняе, як арыгінал, без якога-небудзь дадатковую інфармацыю аб часовым адсутнасць перакладу пастаўшчыкоў .

Незалежна ад таго, якім чынам гэта будзе зроблена, Google будзе разглядацца як адзін API (v1 або v2 у залежнасці ад канфігурацыі) - няма сэнсу, каб разбіць яго, таму што Google v1 будзе зачыненая ў бліжэйшы час.

Іншая справа, каб наладзіць правайдэраў чаргу для кожнай моўнай пары асобна. У гэты момант Б. прадпрыемства ўжо дазваляе наладзіць пераклад пастаўшчыка для кожнай моўнай пары. Я думаю, што мы можам змяніць яго ад аднаго значэння да значэнняў, падзеленых коскамі (CSV). Такім чынам, мы будзем ведаць, для кожнай моўнай пары, якія правайдэры падтрымліваюць гэтую перакладзе і якія парадку перавагі (справядлівы парадак у спісе CSV).

Звярніце ўвагу: гэта будзе мець некаторы ўплыў на прадукцыйнасць у любым выпадку. Замест таго каб ствараць адзін аб'ект для перакладу, нам давядзецца стварыць масіў такіх аб'ектаў і дадатковы аб'ект ўпакоўкі (каб зрабіць яго празрыстым для іншых частак кода і менш памылак схільнымі). Вядома, мы не будзем ствараць аб'екты для пастаўшчыкоў мы ведаем, не даступныя ў дадзены момант.
Рашэнне для гэтага было б пераналадзіць для лепшай прадукцыйнасці і выдаляць правайдэраў чарзе - гэтак жа, як гэта прама цяпер - аднаму асобе ў моўнай пары.
Гэта не павінна быць дарагім для выканання, але ўсё яшчэ некаторыя дадатковыя логікі і памяці.

Калі ласка, скажыце, які варыянт з'яўляецца пераважным.