¿Cuál es la forma más eficaz y accesible de transferir datos desde el back-end al front-end?

La respuesta es completamente circunstancial.

La transmisión real de datos (es decir, el proceso de envío ) es más eficaz de una manera no encriptada y comprimida. El cifrado (SSL / TLS) normalmente aumenta el tamaño de los datos, por lo que hay más para enviar. Cuanto más pequeño es el conjunto de datos, más rápido se envía. En la vida real, el envío de datos sin cifrar es a menudo una mala estrategia. Sin embargo; el cifrado / compresión agrega operaciones adicionales. El punto es que hay una diferencia entre entregar los datos y cuándo el usuario realmente los verá.

Incrustar datos en una página y recuperarlos en una llamada separada es donde la respuesta “depende” puede llevarlo en muchas direcciones. El rendimiento se trata de la asignación de recursos informáticos. Si su servidor no es terriblemente poderoso y recibe muchas solicitudes simultáneas que todos necesitan para procesar páginas, podría convertirse en un cuello de botella y ralentizar las cosas. Todo el procesamiento de datos inicial se realiza en un servidor (lo que conduce a la agrupación en múltiples servidores como solución). Tampoco puede aprovechar el almacenamiento en caché si los datos son dinámicos … lo que significa que no puede almacenar en caché el HTML y otros activos en la página. Entonces, aunque solo haya una solicitud de red, esta estrategia puede aumentar la latencia.

Usar AJAX es un medio de distribuir la capacidad informática. En lugar de confiar en el servidor para procesar todo, la página ahora puede usar los recursos del dispositivo cliente. Esto se vuelve más complicado con las aplicaciones de IoT, pero las capacidades del navegador han hecho avances enormes (y a menudo inadvertidos) en este espacio.

Por ejemplo, preconnect atributos predns y preconnect para una etiqueta . Notará que estas etiquetas ayudan al navegador a controlar las solicitudes de red, aprovechando el almacenamiento en caché de los activos que no son de datos. En muchos casos, esto puede aumentar sustancialmente el rendimiento percibido, incluso si carga sus datos en una solicitud por separado.

También es importante pensar en cosas como localStorage , que puede almacenar en caché los datos para eliminar potencialmente las solicitudes de datos por completo (después de la primera carga). Los trabajadores de servicios (que se están volviendo cada vez más comunes) también permiten un mayor control sobre la red, haciendo que cosas como la carga de datos predictivos sean más accesibles para el desarrollador promedio.

Finalmente, los datos se pueden recuperar de diferentes fuentes simultáneamente. Si escala una aplicación para usar múltiples API, puede “canalizar” los datos. Incluso los navegadores web más antiguos pueden admitir hasta 6 solicitudes HTTP simultáneas (las más nuevas que ejecutan HTTP2 son mucho mayores) … es la forma en la web de hacer hyperthreading.

Hay un montón de factores en el rendimiento. Es toda una subsector dentro del desarrollo web.

Hay casos de uso para ambos escenarios. Recientemente incruste datos específicos del usuario en una página porque el servidor estaba usando autenticación basada en sesión. Los datos específicos del usuario se integraron en la página, pero la carga principal de datos se sirvió desde una API a través de AJAX. El punto es que las soluciones híbridas son posibles, y el truco es saber cómo equilibrar el rendimiento con la productividad y las capacidades de todo el sistema.

Puedo entender hacia dónde intenta llegar, pero creo que hay varios factores diferentes. ¿Se refiere a la experiencia del usuario, la carga del servidor, la accesibilidad o la velocidad general / global?

Re: la experiencia del usuario, generalmente cargaba la página lo más rápido posible y luego llamaba al conjunto de datos después de eso a través de ajax … mostrando un estado de carga mientras está esperando para cargar.

Desde una perspectiva de accesibilidad, creo que en estos días hay poca diferencia. Los lectores de pantalla, etc., son lo suficientemente buenos como para poder “ver” el contenido cargado de ajax.

Desde la perspectiva de la carga del servidor, me gusta dividir la página en elementos manejables (al hacer una carga ajax). De esta manera, tengo más control sobre el almacenamiento en caché de diferentes contenidos, u optimizo específicamente el tiempo de carga de forma aislada.

Es difícil tomar decisiones definitivas sin todos los detalles, pero mi llamada general sería cargarlo a través de ajax … intentar cargarlo en línea parece que podría ser bastante complicado para casi ninguna mejora en el rendimiento.