Circular control i commutació de les API per mantenir el flux de les traduccions

[vBET]

Jo entenc la seva descripció i el seu punt. Ara hem de esbrinar com se suposa que el treball tècnic.

Un problema que veig aquí és com anem a reconèixer que ja tenim límits disponibles després d'aquelles en les que va arribar abans.

Podem simplement cada vegada que demani al proveïdor preferit i després anar a la següent. Això tindrà un cost de rendiment - ja que per cada sol.licitud de pàgina que requereix la traducció, que es fa dir sense èxit als proveïdors preferits, i després a un costat (el que pot ser de diverses trucades sense èxit quan VBET donarà suport més API).

Una altra solució seria la d'emmagatzemar la informació que el proveïdor preferit no està disponible i anar directament a la següent. Això seria molt més ràpid, perquè la comprovació variable local és molt més ràpid que esperar la resposta des d'un servidor extern. Aquesta vegada tenim un altre assumpte - no sabem quan el proveïdor preferit està disponible. Podem, per descomptat, va fer una tasca programada que demanaria simple (curta) la traducció, per exemple, un cop per hora / dia per comprovar-ho. Així que en aquesta estratègia que hem de decidir amb quina freqüència per defecte aquesta tasca suposa per al treball. Per descomptat que ho comprovaria només quan un distribuïdor es marca com a no disponible.
A més, si es marca com a no disponible proveïdors - el que ha de fer quan sabem que tots els proveïdors no estan disponibles - afegir una mica d'informació per a l'usuari final o simplement traduir el que està en la memòria cau i la resta com a original, sense cap tipus d'informació addicional sobre la manca temporal de proveïdors de traducció .

No importa la forma en què es durà a terme, Google serà tractat com un API (v1 v2 o depenent de la configuració) - no té sentit per dividir-lo, ja que Google v1 es tancarà molt aviat.

Una altra cosa és que permeten configurar la cua dels proveïdors per a cada parell d'idiomes per separat. En aquest moment ja VBET permet configurar el proveïdor de traducció per a cada parell d'idiomes. Crec que podem canviar d'un valor als valors separats per comes (CSV). D'aquesta manera sabrem que per a cada parell d'idiomes que els proveïdors de suport a aquesta traducció i quines són les preferències d'ordre (ordre just a la llista CSV).

TINGUI EN COMPTE: això tindrà algun impacte en el rendiment de totes maneres. En lloc de crear un objecte de la traducció, haurem de crear la matriu d'objectes, i l'objecte embolcall addicional (perquè sigui transparent per a altres parts de codi i menys propensos a errors). Per descomptat no anem a crear objectes per als proveïdors sabem que no estan disponibles en aquest moment.
Solució per això seria tornar a configurar per a un millor rendiment i eliminar la cua dels proveïdors - com ho és ara - un proveïdor per parell d'idiomes.
Això no ha de ser car per al rendiment, però tot i així una mica de lògica addicional i el consum de memòria.

Si us plau, digui quina és la solució preferida.