Representación del lado del servidor frente al lado del cliente
En los viejos tiempos, casi todo el renderizado se realizaba en el lado del servidor, ya sea:
- dinámicamente sobre la marcha cuando se recibe una solicitud (en PHP, ASP, Perl, Java, …),
- en horarios programados de actualización,
- o cada vez que se realiza una modificación en el servidor.
Dado que JavaScript y DOM están disponibles en el cliente, ha sido posible modificar la representación en el lado del cliente, y Ajax lo hizo aún más fácil.
- ¿Cuál es la última tendencia en arquitecturas de aplicaciones web?
- ¿Qué es la representación del lado del servidor? ¿Por qué es necesario en MeteorJS o en cualquier otro idioma?
- Cómo convertir formatos de video / audio en la aplicación web NodeJS
- ¿Cuáles son algunos patrones comunes de arquitectura de servidor para aplicaciones altamente escalables?
- ¿Cuál es la diferencia entre un sitio web 'simple' y una aplicación web?
La representación del lado del servidor es muy recomendable para que los buscadores puedan analizar fácilmente el sitio web orientado al contenido. También puede ser más amigable con los dispositivos móviles a nivel de computación y luego potencialmente preservar la batería, tiene un costo a nivel de comunicación ya que todas las actualizaciones necesitan recargar una gran cantidad de HTML.
Con la representación del lado del cliente, es posible hacer que casi todo el diseño HTML se pueda almacenar en caché, como suelen ser los scripts y los archivos CSS. El cliente, en el nivel extremo, solo tendrá que cargar el HTML una vez, y todos los datos se pueden cargar en un formato JSON más ligero para representar el lado del cliente en JavaScript con libs como Mustache.js, Handlebar, Underscore, AngularJS o Casi cualquier marco. Es más apropiado para aplicaciones web que no necesitan ser analizadas por los motores de búsqueda. El Marco Wakanda Ajax utiliza este enfoque en el nivel extremo para las “páginas” o “componentes” HTML de la aplicación. Este enfoque a menudo se adapta aún más cuando se crean aplicaciones web móviles híbridas, ya que todos estos diseños HTML estáticos se pueden integrar fácilmente en el paquete de aplicaciones móviles.
Algunas soluciones proponen renderizar en ambos lados. Por lo general, la representación del lado del cliente es la primera opción utilizada, mientras que una URL alternativa compatible con Google proporcionará el mismo contenido de la representación del lado del servidor. Dicha solución se ha vuelto un poco más fácil de hacer consistentemente, ya que con JavaScript del lado del servidor, las mismas plantillas y motores de plantillas se pueden usar en ambos lados para obtener exactamente el mismo resultado.
El lado del servidor también se puede utilizar para proporcionar formatos alternativos que HTML como PDF, Excel, archivos zip, imágenes. La mayoría de estos formatos eran difíciles, si no imposibles, de generar del lado del cliente en JavaScript, pero desde que aparecieron las nuevas características HTML5, comenzó a ser posible.
Las principales preguntas de hoy se vuelven entonces:
- ¿Quiero que mi aplicación sea lo más independiente posible en el lado del cliente, incluso en modo fuera de línea?
- ¿O prefiero mantenerlo ligero y diferir algunas tareas al servidor?
Su elección probablemente dependerá de:
- las capacidades de su servidor para manejar su cantidad de clientes conectados
- la capacidad / poder de sus clientes objetivo
- la velocidad de red esperada
Los teléfonos inteligentes y tabletas modernos son cada vez más potentes y el cuello de botella suele estar en el nivel de la red. En este caso, la representación del lado del cliente puede ser excelente (incluso más para el modo fuera de línea)
Algunos usuarios todavía están limitados a teléfonos más ligeros, en cuyo caso la representación del lado del servidor puede ayudar. Las aplicaciones avanzadas también pueden detectar la velocidad de la red y elegir la representación del lado del servidor cuando es lo suficientemente grande en comparación con el costo de la representación del lado del cliente (como cuando se generan imágenes dinámicas).
Restricciones de Meteor.js
Meteor.js está dedicado a aplicaciones de comunicación en tiempo real y depende en gran medida de Web Sockets. En algunas situaciones, la conexión de Web Socket puede llevar tiempo (incluso más en móviles), lo que tendrá un impacto en la velocidad del renderizado.
La solución propuesta es, por lo general, utilizar primero la representación del lado del servidor, tener algo que mostrar mientras se espera la conexión de Web Socket y luego actualizar la vista en “tiempo real” una vez que sea posible. También se propone una alternativa llamada Fast Render para permitir la representación del lado del cliente antes de que se realice la conexión Web-Socket.
