Repensar la interfaz
En primer lugar, un diseño de interfaz de usuario que muestre de 50 a 100 000 filas en un cliente probablemente no sea la mejor interfaz de usuario en primer lugar. No solo es una gran cantidad de datos para enviar al cliente y para que el cliente los administre y quizás no sea práctico en algunos dispositivos móviles, sino que obviamente son muchas más filas de las que un solo usuario realmente leerá en cualquier interacción dada con la página. Entonces, el primer orden podría ser repensar el diseño de la interfaz de usuario y crear algún tipo de interfaz más impulsada por la demanda (paginada, desplazamiento virtual, tecleada por letra, etc.). Hay muchas posibilidades diferentes para un diseño de interfaz de usuario diferente (y con suerte mejor) que disminuya la cantidad de transferencia de datos. Qué diseño sería el mejor depende completamente de los datos y los modelos de uso probables del usuario.
Enviar datos en fragmentos
Dicho esto, si iba a transferir tantos datos al cliente, entonces probablemente querrá enviarlos en fragmentos (grupos de filas a la vez). La idea con los fragmentos es que envíe una cantidad consumible de datos en un fragmento de modo que el cliente pueda analizarlos, procesarlos, mostrar los resultados y luego estar listo para el siguiente fragmento. El cliente puede permanecer activo todo el tiempo ya que tiene ciclos disponibles entre fragmentos para procesar otros eventos de usuario. Pero enviarlo en fragmentos reduce la sobrecarga de enviar un mensaje separado para cada fila. Si su servidor está usando compresión, entonces los fragmentos también brindan una mayor oportunidad de eficiencia de compresión. El tamaño que debe tener un fragmento (por ejemplo, cuántas filas de datos debe contener) depende de una serie de factores y es probable que se determine mejor a través de la experimentación con clientes probables o con el cliente de menor potencia esperado. Por ejemplo, es posible que desee enviar 100 filas por mensaje.
Utilice un formato de transferencia eficiente para los datos
Y, si usa socket.io para transferir grandes cantidades de datos, es posible que desee revisar cómo usa el formato JSON. Por ejemplo, enviar 100 000 objetos que repiten exactamente los mismos nombres de propiedad no es muy eficaz. A menudo puede inventar sus propias optimizaciones que evitan repetir nombres de propiedades que son exactamente iguales en todos los objetos. Por ejemplo, en lugar de enviar 100 000 de estos:
{"firstname": "John", "lastname": "Bundy", "state": "Az", "country": "US"}
si cada objeto tiene exactamente las mismas propiedades, puede codificar los nombres de las propiedades en su propio código o enviar los nombres de las propiedades una vez y luego simplemente enviar una lista de valores separados por comas en una matriz que el código receptor puede colocar en un objeto con los nombres de propiedad apropiados:
["John", "Bundy", "Az", "US"]
El tamaño de los datos a veces se puede reducir de 2 a 3 veces simplemente eliminando la información redundante.
