Debo hacer llamadas más frecuentes y más pequeñas; o llamadas más grandes menos frecuentes?

Question

Supongo que la pregunta está un poco cargada, pero quería algunos comentarios. Actualmente estoy construyendo objetos de clase poco desde servicios web a través de dtos. Precarbo todos los valores escalares y cargas lazy todas las colecciones/matrices, que incluyen binarios, por supuesto.

Obviamente, hice esto para mejorar el tiempo de respuesta, ya que esta biblioteca es lo que impulsa la aplicación web. Pero, para mantener el servicio reutilizable, he normalizado cada función GET en una sola acción (S). Entonces, por ejemplo, agarrar información del usuario del directorio activo es uno (valores escalares como displayName y departamento, por ejemplo), y capturar los informes directos de esta persona es una acción separada, con carga diferida. Entonces, qué sucede, es que cuando estás construyendo un objeto, hay numerosas llamadas al servicio para construir este objeto. Algunas páginas solo necesitan la información básica, otras llamarán a más métodos de carga diferida o incluso a todo el objeto. No veo un problema con esto, pero lo que me pregunto (y otros en el trabajo ya están criticando) es si esto va a ser un problema.

Mi pregunta es, ¿lo estoy haciendo mal? Toda la entrada es apreciada sin embargo. Gracias

Answer 1

El saldo que debe alcanzar es la sobrecarga de realizar una llamada HTTP, en comparación con la sobrecarga de la transferencia de una solicitud o respuesta grande.

No hay una bala de plata. Por ejemplo, si la llamada se realiza de un servidor a otro a través de una LAN, las cargas útiles más grandes no son un gran problema. Si la llamada se realiza desde un dispositivo móvil, entonces recortar la carga útil probablemente tendrá mucho beneficio.

El mejor equilibrio para comenzar es ver los métodos de su servicio web como pasos en un flujo de trabajo. Piense en "Si quiero lograr X, ¿qué datos necesitaré?"; intente enfocar las respuestas de sus solicitudes en torno a esos pensamientos y luego analizar los resultados. Es solo un punto de partida, pero es mejor que comenzar con "un método para cada pequeño detalle" o "un método que permite todo".

Answer 2

No veo ningún problema con esto, pero lo que me pregunto (y otros en el trabajo ya están criticando) es si esto va a ser un problema.

El problema es que cada llamada al servicio proporciona una sobrecarga. Obtendrá un mejor rendimiento total con menos llamadas más grandes.

Siempre hay un intercambio aquí, y un equilibrio para alcanzar. Las llamadas más grandes corren el riesgo de obtener más datos de los necesarios, lo que también es un desperdicio de recursos.

Answer 3

Voto por llamadas más grandes y menos frecuentes.

Dado que se encuentra en un contexto web, es una operación costosa para que los datos pasen de la tienda de datos al nivel de su aplicación y luego a su nivel web, creo que la red atrapa la mayor cantidad de recursos. Por lo tanto, las llamadas menos frecuentes (a través de un mecanismo de caché en el nivel web) escalan mejor y esto proviene de la experiencia personal.

Además, lo que defina como "grande" depende del uso de su aplicación. P.ej. Si la mayoría de sus usuarios solo ven su información básica y solo unos pocos ingresan a informes directos, puede usar dos llamadas separadas. De lo contrario, quédate con uno.

Espero que esto ayude.