Pros / contras entre enfatizar el procesamiento del lado del cliente o del lado del servidor

¿Por qué querría escribir una aplicación web con mucho procesamiento del lado del servidor?

Para mí, escribir el programa en el lado del cliente es una gran ventaja porque quita la mayor carga de servidor posible porque solo tiene que enviar datos al cliente con un procesamiento mínimo.

Veo muy poco en escribir aplicaciones web además de escribirlo en el lado del servidor y tratar el lado del cliente como solo una vista . ¿Por qué querría hacer esto? La única ventaja que veo es que puedo escribir en el idioma que quiera ( http://www.paulgraham.com/avg.html ).

Hay dos problemas principales.

1. La primera es fácil: generalmente no sabe qué tipo de recursos están disponibles en el lado del cliente. Si requiere 1,5 GB para procesar algo, ¿puede realmente insertarlo en un navegador de cliente desconocido (IE, Safari, Opera, Firefox, etc.) en una plataforma de cliente desconocida? ¿El cliente apreciará su sistema de persecución cuando lo abrumes?

2. El segundo es más arquitectónico: ¿qué capas quieres exponer al mundo exterior? La mayoría estaría de acuerdo en que es increíblemente arriesgado exponer su capa de datos. ¿Qué tal su capa de servicio? ¿Realmente quieres entregar esa lógica por ahí? Si lo hace, ¿también está exponiendo los puntos de entrada a su capa de datos? Si mantiene el lado del servidor de la capa de servicio, ¿qué queda? La interfaz de usuario, ¿verdad? Consulte la razón 1 para obtener información sobre cuánto de eso vive en el servidor y cuánto en el cliente.

Primero y principal es la seguridad . Empuje toda su lógica al cliente y es un juego justo para hackers y exploits.

Todo lo que tenga un valor percibido no durará 5 minutos, especialmente el valor monetario, y se jugará o pirateará o explotará y dañará su sistema bastante mal. Incluso si tiene poco o ningún valor monetario, hay una clase de personas que lo piratearán solo para romper su sistema porque están aburridos.

Lado del cliente versus lado del servidor

El procesamiento del lado del cliente está en línea con los estándares REST más populares, así como MVC en lugar de los enfoques basados ​​en páginas y SOAP. La aparición de estas tendencias y el enfoque en AJAX y Html-RIA, la creación de scripts del lado del cliente está en aumento y es más popular; sin embargo, debido a problemas de seguridad y capacidad del cliente, las secuencias de comandos del lado del cliente tienen un nicho particular y no deben usarse para todo.

Consideraciones:

Móvil

Si un gran segmento de su público objetivo serán usuarios móviles, el procesamiento pesado debe dejarse en manos del servidor.

Consistencia entre navegadores

Los estándares web han recorrido un largo camino y esto puede no ser una gran preocupación, pero todos los desarrolladores web saben que IE 6,7 y 8 y, a veces, Safari pueden actuar de manera divertida en el lado del cliente; ciertas funciones pueden no ejecutarse debido a restricciones de seguridad y otras debido a estándares no implementados. También es importante tener en cuenta que el usuario final puede configurar un navegador para que tenga ciertas restricciones o incluso desactivar por completo el procesamiento del lado del cliente (¡sin javascript!). Si la coherencia es un requisito para el 100% de los usuarios (y especialmente si está haciendo algo poco ortodoxo), el lado del servidor es lo más importante.

Seguridad

Cualquier manipulación de datos que desee proteger debe realizarse en el servidor. Cualquier dato que se procese en el lado del cliente está absolutamente abierto a manipulación. Por ejemplo, si tiene una función de JavaScript que procesa cierta información que luego se vuelve a publicar en el sistema, sería muy fácil manipular el resultado justo antes de que se vuelva a publicar, incluso si tiene una seguridad de fondo ejemplar

UI / UX

Se deja el procesamiento del lado del cliente para la interfaz de usuario y se crean aplicaciones de Internet enriquecidas (RIA). Se utiliza para crear animaciones, efectos, interacciones del usuario, así como para cargar dinámicamente contenido a través de llamadas AJAX en lugar de volver a cargar una página completa.

Principalmente será una duplicación de esfuerzo. Lo más probable es que cualquier dato del cliente haya sido revisado y procesado a nivel del servidor nuevamente.

El servidor no puede asumir que su cliente rico / robusto envió los datos, por lo que con cualquier cosa que se envíe, el servidor debe validarlos y procesarlos. Entonces tiene sentido ponerlo allí.

Sin embargo, creo que se puede hacer algo de lógica a nivel del cliente para una mejor experiencia de UI.

Tienes razón, por qué enviar datos al servidor si no está completo o es incorrecto. Es fácil verificar los campos obligatorios o los teléfonos o direcciones de correo electrónico con el formato correcto. Nunca me gustó enviar un formulario y luego esperar 5 segundos para decirme que olvidé ingresar un campo. Ese tipo de procesamiento, seguro, lo hace en el cliente y asegúrese de que sea correcto y utilice la lógica del lado del cliente para una respuesta rápida al usuario. Como ha señalado, un efecto secundario adicional sería que su servidor tendría que lidiar con solicitudes de datos menos malas. PERO, el servidor todavía tiene que validar también, por lo que está duplicando la lógica. Pero, sus usuarios serán más felices.

Hay una línea muy fina aquí. La lógica de validación simple está bien, la lógica empresarial central no está bien.

1. En primer lugar, debe comprender la arquitectura de las aplicaciones web, la mayoría, si no todas, son de 3 niveles:

   a) Cliente / Presentación: HTML y Javascript, pueden contener ActiveX / Flash / Java Applets / Silverlight. Me arriesgaré y agregaré aplicaciones móviles nativas que se comunican con un servidor de fondo. Básicamente, el papel de esta capa es proporcionar una interfaz para que el usuario del sistema interactúe con ella.

   b) Business Logic: PHP / RoR / Java donde se recopilan, procesan y almacenan los datos del cliente y donde las solicitudes de datos del cliente se procesan y envían de vuelta al cliente

   c) Almacén de datos de backend: proporciona almacenamiento persistente para la información del sistema

2. Entonces, ¿dónde se realiza la validación, en todas las capas? ¿Por qué?

   a) Del lado del cliente: asegúrese de que el usuario ingrese los datos correctos, los campos obligatorios, etc.

   b) Lógica empresarial: filtra, desinfecta y valida los datos del cliente. Ejecute reglas comerciales más complejas para garantizar que los datos estén bien formados para el almacenamiento. Aquí se repite parte de la validación realizada en el front-end, debido al hecho de que puede haber diferentes clientes, por ejemplo, los navegadores, el Javascript se puede deshabilitar. También puede aceptar datos de diferentes fuentes a través de API, por ejemplo, por lo que todo debe ser validado.

   c) Almacenamiento de datos de backend: las restricciones aseguran que los datos estén bien formados para el almacenamiento y la recuperación posterior.

Entonces, ¿dónde enfoca sus esfuerzos de validación, use cada capa para realizar la validación que mejor se adapte y deje reglas más complejas para la capa que puede manejarla?

Una gran parte es mantener su procesamiento cerca de sus datos. Si tiene cientos de GB de datos, obviamente no lo enviará a un cliente. Con el aumento de la velocidad de acceso a los datos, esto se está convirtiendo en un problema menor, pero si tiene un sitio de Big Data, aún desea filtrar y reducir tanto como sea posible en el servidor antes de enviarlo.

Cuando crea su comportamiento completamente en el lado del cliente (por ejemplo, con Javascript), el SEO puede convertirse en un problema.

Las soluciones web que mantienen mucho en el lado del servidor son más fáciles de mantener contenido específico publicado en una URL específica (generalmente RESTful), de una manera que sea visible para los motores de búsqueda.

Esto también significa que un visitante puede marcar una página específica. ¿Has probado eso en Facebook?

Esto se puede resolver, pero generalmente está integrado en aplicaciones que hacen mucho en el servidor (RAILS, WordPress, etc.), mientras que si está construyendo en REACT, tendrá que saltar a través de los aros.

La razón es la estabilidad .

En el lado del servidor, puedo elegir componentes estables. Por lo general, esto significa que elijo Java y un montón de bibliotecas cuidadosamente seleccionadas, como FreeMarker. No hace falta decir que todas las bibliotecas, aparte de las bibliotecas estándar de Java, se tratan como desechables, por lo que accedo a las bibliotecas externas a través de un envoltorio hecho a sí mismo. Esto significa que puedo cambiar fácilmente de una biblioteca a otra si surge el requisito.

Cada vez que actualizo Java a una nueva versión, generalmente funciona bien porque Java es un componente extremadamente estable incluso en las actualizaciones de versiones principales. Y también, cada servidor que tengo está ejecutando la misma versión de Java. No todos los clientes ejecutan la misma implementación de JavaScript.

En el lado del cliente, no puedo elegir componentes estables. Los fabricantes de navegadores me obligarán a elegir JavaScript, un idioma que particularmente no me gusta, pero que me veo obligado a usar. (Y no me hable de los lenguajes que están compilados en JavaScript, ¡son horribles!) La implementación de JavaScript de cada navegador es diferente. Esto significa que es un infierno probar mi producto con cada versión de navegador compatible.

¿Mi solución? Realizo todo el procesamiento que puedo en el lado del servidor, y el lado del cliente es solo un contenedor ligero que envía datos al servidor y recibe datos del servidor en forma de fragmentos JSON y HTML. Evitar XML; use JSON en su lugar.

No hago plantillas del lado del cliente; Represento el contenido en el servidor a un fragmento HTML que luego asigno usando el .innerHTMLatributo a varios elementos de marcador de posición en el lado del cliente. Esto mantiene la pila de tecnología lo más simple posible, porque no necesito dos motores de plantilla (uno de Java y uno de JavaScript).

El inconveniente es obviamente la latencia de la velocidad de la luz; medio segundo de latencia no es infrecuente entre continentes.

Considere que sus clientes en estos días pueden ser teléfonos inteligentes. Los teléfonos inteligentes tienen una duración limitada de la batería, por lo que si está haciendo un cálculo pesado, es mejor descargarlo a sus servidores. Sin embargo, las cosas simples pueden ser más eficientes energéticamente cuando se realizan en el lado del cliente porque así puede evitar el acceso a la radio. Pero el argumento principal, la estabilidad, puede significar que en realidad puede tener sentido descargar incluso el cómputo simple al servidor.

Como anexo, como ya se observó en algunas respuestas, también obtiene seguridad . Si la lógica de la aplicación está totalmente del lado del cliente, alguien puede, por ejemplo, establecer un precio para cualquier cosa que vaya a comprar en su tienda web en línea.