¿Demasiadas llamadas a la API REST en una página?

8

Una aplicación web diseñada con componentes pequeños y altamente modulares (en este caso, usando directivas AngularJS, pero podría ser fácilmente WebComponents, componentes ReactJS o cualquier otra tecnología). Los componentes a menudo tienen llamadas asíncronas de API REST, tras la inicialización o la interacción del usuario. Este diseño está causando muchas llamadas API por página (a veces más de 20). ¿Hay algún problema con este diseño? Algunos sugieren que condensamos las llamadas de API en servicios más grandes del lado del cliente que actúan como singletons. Por lo tanto, 10 llamadas API pueden reducirse a 1, aunque una página solo puede usar una parte de esos datos. ¿Hay banderas rojas o problemas con este diseño? ¿Cuál debería preferirse?

rest api async

— Ryan Langton
fuente

Creo que mucho de esto depende de la latencia que experimente y del impacto que tenga en el usuario (¿lo notan?)

— Niall

Estas son llamadas asincrónicas y la mayoría ocurren de una vez (inicialización de página). Por lo tanto, el usuario solo verá una pantalla ligeramente atenuada y una barra de carga hasta que se carguen todos los datos. Creo que es una buena experiencia de usuario. Mi única preocupación es el volumen de llamadas al servidor, ¿es un problema (limitaciones de la API, etc.)? En una aplicación tradicional, haría una sola llamada al servidor por página.

— Ryan Langton

1

No conozco ninguna limitación de antemano. Suena como una compensación; diseño vs. mantenimiento vs. latencia vs. etc. Prefiero menos, pero que los datos todavía son relevantes para la llamada (es decir, si los datos requeridos no son relevantes para la llamada API, entonces haga una llamada separada). Lo admito, creo que este es un 6 de uno, media docena del otro.

— Niall

Considere actualizar su servidor a HTTP 2.

— CodesInChaos

2

Los navegadores limitan el número total de solicitudes concurrentes

/programming/561046

Entonces sí, hay un problema con este diseño. Sin embargo, creo que la respuesta aceptada es pasar a una implementación de sockets web donde use una sola conexión, pero con muchos tipos de mensajes para comunicarse con el servidor

— Ewan
fuente

1

Esto no parece ser un problema ya que el límite es por navegador. Entonces, si hay más de 6 llamadas, las demás solo se pondrán en cola. Acordó que la conexión de socket web sería más eficiente, pero no estoy seguro si es necesario.

— Ryan Langton

depende de cómo estés usando esas llamadas, supongo. El problema principal es que a medida que el código del lado del cliente se complica cada vez más, comienza a encontrarse con las limitaciones de JavaScript. p.ej. codificación de un cliente de socket de agrupación de conexiones en un idioma diseñado para cambiar el color del texto en un mouseover

— Ewan

"Entonces sí, hay un problema con este diseño", que parece una declaración general. Hay muchas maneras en que este diseño se puede implementar con éxito.

— richard

2

Este diseño está causando muchas llamadas API por página (a veces más de 20). ¿Hay algún problema con este diseño?

No debería haberlo. El hecho de que cada solicitud sea pequeña y asíncrona significa que puede acelerar enormemente su aplicación web, en lugar de tener que esperar a que se complete una sola solicitud grande que bloquea todo.

Solo asegúrate de que tu javascript sea correctamente asíncrono y pueda hacer cosas mientras tus otras solicitudes están esperando y terminarás con una aplicación mucho mejor que si tuvieras una solicitud masiva que obtuviera todo.

Después de que todos los navegadores están diseñados para manejar la carga de muchas URL en tándem, incluso una página web estándar típica puede tener decenas, si no cientos de solicitudes de imágenes, CSS, JavaScript, iframes, etc.

— Cormac Mulhall
fuente

1

No olvide el tamaño de cada solicitud de red. En general, si cada solicitud solo devuelve como 2 KB de datos, entonces la solicitud de red es demasiado costosa para esa pequeña cantidad de datos.

Si la solicitud de red sube a 400 KB, divídala en dos. Pero, en general, el problema no suele ser suficiente información para una sola solicitud de red.

— dman
fuente

0

Algunas consideraciones aquí:

Actuación

Si está viendo un rendimiento aceptable, no debe preocuparse demasiado por ello. Si puede ejecutar HTTP2, debería ver un aumento en el rendimiento. ^[1] .

Diseño

Al igual que con cualquier diseño, no existen reglas estrictas en cuanto a si debe hacer muchas solicitudes pequeñas o pocas solicitudes grandes. Algunas cosas a considerar:

¿Son muchas de las llamadas interdependientes? Si tiene una relación de dependencia compleja entre diferentes llamadas, puede dificultar el mantenimiento. Si este es el caso, los datos de respuesta relacionados con el procesamiento por lotes tendrían sentido.
¿Los diferentes componentes comparten gran parte de los mismos datos? Si este es el caso, podría tener un punto central que haga las llamadas compartidas y permita que los componentes accedan a los datos compartidos.
Vigile la carga de mantenimiento de los componentes pequeños que realizan llamadas separadas. Sabrá cuándo se vuelve difícil de administrar y luego puede ser necesario un cambio. Cambiar un diseño basado en necesidades hipotéticas futuras puede causar errores de diseño, ya que debe anticipar con precisión qué problemas tendrá en el futuro. Si está funcionando bien ahora, cambiarlo también sería innecesario.

1: "HTTP / 2 está completamente multiplexado, lo que permite transferir múltiples archivos y solicitudes al mismo tiempo, a diferencia de HTTP1.x que solo aceptaba una sola solicitud / conexión a la vez. HTTP / 2 usa la misma conexión para transferir diferentes archivos y solicitudes, evitando la pesada operación de abrir una nueva conexión para cada archivo que debe transferirse entre un cliente y un servidor ". - https://css-tricks.com/http2-real-world-performance-test-analysis/

— Tjaart
fuente