performance - servidor - patrones de diseño de software mvc

¿Lógica del lado del cliente O lógica del lado del servidor? (11)

Creé una aplicación web RESTful donde todas las funcionalidades de CRUD están disponibles en ausencia de JavaScript, en otras palabras, todos los efectos de AJAX son mejoras estrictamente progresivas .

Creo que con la dedicación suficiente, la mayoría de las aplicaciones web pueden diseñarse de esta manera, erosionando muchas de las "diferencias" de la lógica del servidor frente a la lógica del cliente, como la seguridad, la capacidad de expansión, planteadas en su pregunta porque en ambos casos, la solicitud se enruta al el mismo controlador, cuya lógica comercial es la misma hasta la última milla, donde JSON / XML, en lugar del HTML de página completa, se devuelve para esos XHR.

Solo en algunos casos donde la aplicación AJAXified es tan vastamente más avanzada que su contraparte estática, GMail es el mejor ejemplo que se me viene a la mente, entonces uno necesita crear dos versiones y separarlas por completo (Felicitaciones a Google!).

He hecho algunos proyectos basados en la web, y la mayoría de las dificultades con las que me he encontrado (preguntas, confusiones) podrían resolverse con ayuda. Pero todavía tengo una pregunta importante, incluso después de preguntar a algunos desarrolladores experimentados: cuando la funcionalidad se puede implementar tanto con el código del lado del servidor como con el scripting del lado del cliente (JavaScript), ¿cuál debería preferirse?

Un simple ejemplo:

Para renderizar una página html dinámica, puedo formatear la página en el código del lado del servidor (PHP, python) y usar Ajax para buscar la página formateada y procesarla directamente (más lógica en el lado del servidor, menos en el lado del cliente).

También puedo usar Ajax para buscar los datos (no formateados, JSON) y utilizar secuencias de comandos del lado del cliente para formatear la página y procesarla con más procesamiento (el servidor obtiene los datos de una base de datos u otro y los devuelve al cliente) con JSON o XML. Más lógica en el lado del cliente y menos en el servidor).

Entonces, ¿cómo puedo decidir cuál es mejor? ¿Cuál ofrece mejor rendimiento? ¿Por qué? ¿Cuál es más amigable para el usuario?

Con la evolución de los motores JS de los navegadores, JS se puede interpretar en menos tiempo, entonces ¿debería preferir el scripting del lado del cliente?

Por otro lado, con la evolución del hardware, el rendimiento del servidor está creciendo y el costo de la lógica del lado del servidor disminuirá, entonces ¿debería preferir el scripting del lado del servidor?

EDITAR:

Con las respuestas, quiero dar un breve resumen.

Pros de la lógica del lado del cliente:

Mejor experiencia de usuario (más rápido).
Menos ancho de banda de red (menor costo).
Mayor escalabilidad (menor carga del servidor).

Ventajas de la lógica del lado del servidor:

Temas de seguridad.
Mejor disponibilidad y accesibilidad (dispositivos móviles y navegadores antiguos).
Mejor SEO.
Fácilmente ampliable (puede agregar más servidores, pero no puede hacer que el navegador sea más rápido).

Parece que necesitamos equilibrar estos dos enfoques cuando enfrentamos un escenario específico. ¿Pero cómo? ¿Cuál es la mejor práctica?

Usaré la lógica del lado del cliente excepto en las siguientes condiciones:

Seguridad crítica.
Grupos especiales (JavaScript deshabilitado, dispositivos móviles y otros).

Creo que la segunda variante es mejor. Por ejemplo, si implementa algo como ''skins'' más tarde, se agradecerá a sí mismo por no formatear html en el servidor :)

También mantiene una diferencia entre la vista y el controlador. Los datos de Ajax a menudo son producidos por el controlador, así que solo devuelva datos, no html.

Si vas a crear una API más tarde, deberás realizar algunos cambios en tu código

Además, creo que los datos ''Naked'' son más cachables que HTML. Por ejemplo, si agrega un poco de estilo a los enlaces, tendrá que reformatear todo html ... o agregar una línea a su js. Y no es tan grande como html (en bytes).

Pero si se necesitan muchos scripts pesados para formatear datos, no es genial pedirles a los navegadores de los usuarios que lo formateen.

En esta etapa, la tecnología del lado del cliente está marcando el camino, con la aparición de muchas bibliotecas del lado del cliente como Backbone, Knockout, Spine y luego con la adición de plantillas del lado del cliente como JSrender, bigote, etc., el desarrollo del lado del cliente se ha vuelto mucho más fácil. entonces, si mi requisito es ir a la aplicación interactiva, seguramente me decantaré por el lado del cliente. En caso de que tenga más contenido html estático, entonces sí, vaya al lado del servidor. Hice algunos experimentos con ambos, debo decir que el lado del servidor es comparativamente más fácil de implementar que del lado del cliente. En lo que se refiere al rendimiento. Lea esto, comprenderá los puntajes de rendimiento del lado del servidor. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

En muchos casos, me temo que la mejor respuesta es ambas .

Como declaró Ricebowl, nunca confíes en el cliente. Sin embargo, creo que casi siempre es un problema si confías en el cliente. Si su aplicación vale la pena escribir, vale la pena protegerla adecuadamente. Si alguien puede romperlo escribiendo su propio cliente y pasando datos que no espera, eso es algo malo. Por ese motivo, debe validar en el servidor.

Desafortunadamente, si valida todo en el servidor, eso generalmente deja al usuario con una experiencia de usuario pobre. Pueden completar un formulario solo para descubrir que una cantidad de cosas que ingresaron son incorrectas. Esto puede haber funcionado para "Internet 1.0", pero las expectativas de las personas son más altas en Internet de hoy.

Esto potencialmente le deja escribiendo un poco de código redundante y manteniéndolo en dos o más lugares (algunas de las definiciones, como las longitudes máximas, también deben mantenerse en el nivel de datos). Para aplicaciones razonablemente grandes, tiendo a resolver este problema usando la generación de código. Personalmente utilizo una herramienta de modelado UML (Enterprise Architect de Sparx System) para modelar las "reglas de entrada" del sistema, luego hago uso de clases parciales (normalmente estoy trabajando en .NET) para generar código de la lógica de validación. Puede lograr algo similar codificando sus reglas en un formato como XML y derivando un número de comprobaciones de ese archivo XML (longitud de entrada, máscara de entrada, etc.) en el nivel del cliente y del servidor.

Probablemente no sea lo que quería escuchar, pero si quiere hacerlo bien, debe aplicar las reglas en ambos niveles.

Me gustaría dar mi granito de arena sobre este tema.

En general, estoy a favor del enfoque del lado del servidor, y aquí está el por qué.

Más SEO amigable. Google no puede ejecutar Javascript, por lo tanto, todo ese contenido será invisible para los motores de búsqueda
El rendimiento es más controlable. La experiencia del usuario siempre es variable con SOA debido a que dependes casi por completo del navegador y la máquina de los usuarios para renderizar las cosas. Aunque su servidor tenga un buen rendimiento, un usuario con una máquina lenta pensará que su sitio es el culpable.
Podría decirse que el enfoque del lado del servidor es más fácil de mantener y legible.

He escrito varios sistemas usando ambos enfoques, y en mi experiencia, el lado del servidor es el camino. Sin embargo, eso no quiere decir que no use AJAX. Todos los sistemas modernos que he construido incorporan ambos componentes.

Espero que esto ayude.

Mientras no necesite enviar una gran cantidad de datos al cliente para que pueda hacer el trabajo, el lado del cliente le dará un sistema más escalable, ya que está distribuyendo la carga a los clientes en lugar de presionar a su servidor para que lo haga. hacer todo.

Por otro lado, si necesita procesar una gran cantidad de datos para producir una pequeña cantidad de html para enviar al cliente, o si se pueden optimizar el uso del trabajo del servidor para admitir muchos clientes a la vez (por ejemplo, procesar los datos una vez) y envíe el html resultante a todos los clientes), entonces puede ser un uso más eficiente de los recursos para hacer el trabajo en su servidor.

Por lo general, implemento tanto como un lado razonable del cliente. Las únicas excepciones que me harían ir al lado del servidor serían resolver lo siguiente:

Problemas de confianza

Cualquiera es capaz de depurar JavaScript y leer contraseñas, etc. No hay nada aquí.

Problemas de desempeño

Los motores de JavaScript están evolucionando rápidamente, así que esto se está convirtiendo en un problema menor, pero aún estamos en un mundo dominado por IE, por lo que las cosas se ralentizarán cuando trabajes con grandes conjuntos de datos.

Problemas de idioma

JavaScript es un lenguaje débilmente tipado y hace una gran cantidad de suposiciones de su código. Esto puede hacer que emplee soluciones escalofriantes para que las cosas funcionen como deberían en ciertos navegadores. Evito este tipo de cosas como la peste.

A partir de su pregunta, parece que simplemente intenta cargar valores en un formulario. Salvo cualquiera de los problemas anteriores, tiene 3 opciones:

Cliente puro

La desventaja es que el tiempo de carga de los usuarios se duplicaría (una carga para el formulario en blanco, otra carga para los datos). Sin embargo, las actualizaciones posteriores al formulario no requerirían una actualización de la página. A los usuarios les gustará esto si habrá una gran cantidad de datos de la carga del servidor en el mismo formulario.

Puro lado del servidor

La ventaja es que su página se cargará con los datos. Sin embargo, las actualizaciones posteriores de los datos requerirían renovaciones para todas / porciones significativas de la página.

Servidor-cliente híbrido

Tendría lo mejor de ambos mundos, sin embargo, necesitaría crear dos puntos de extracción de datos, haciendo que su código se hinchara un poco.

Hay compensaciones con cada opción, por lo que tendrá que sopesarlas y decidir cuál le ofrece el mayor beneficio.

Sé que esta publicación es antigua, pero quería comentar.

En mi experiencia, el mejor enfoque es usar una combinación de cliente y servidor. Sí, Angular JS y frameworks similares son populares ahora y han hecho que sea más fácil desarrollar aplicaciones web que sean ligeras, tengan un mejor rendimiento y funcionen en la mayoría de los servidores web. PERO, el requisito principal en las aplicaciones empresariales es mostrar datos de informes que pueden abarcar más de 500 registros en una página. Con páginas que devuelven grandes listas de datos, los usuarios a menudo desean funciones que hagan que esta gran lista sea fácil de filtrar, buscar y realizar otras funciones interactivas. Debido a que los navegadores IE 11 y anteriores de IE son el "navegador de elección" en la mayoría de las compañías, debe tener en cuenta que estos navegadores aún tienen problemas de compatibilidad al usar JavaScript, HTML5 y CSS3 modernos. A menudo, el requisito es hacer que un sitio o aplicación sea compatible en todos los navegadores. Esto requiere agregar shivs o usar prototipos que, con el código incluido para crear una aplicación del lado del cliente, se agrega a la carga de la página en el navegador.

Todo esto reducirá el rendimiento y puede causar el temido error de IE "Una secuencia de comandos en esta página está causando que Internet Explorer se ejecute lentamente" obligando al usuario a elegir si desea continuar ejecutando la secuencia de comandos o no ... creando malas experiencias de usuario.

Determine la complejidad de la aplicación y lo que el usuario quiere ahora y podría desear en el futuro en función de sus preferencias en sus aplicaciones existentes. Si se trata de un sitio o aplicación simple con datos de poco a medio, use JavaScript Framework. Pero, si quieren incorporar accesibilidad; SEO; o necesita mostrar grandes cantidades de datos, use el código del lado del servidor para representar los datos y el código del lado del cliente con moderación. En ambos casos, use una herramienta como Fiddler o Chrome Developer para verificar la carga de la página y los tiempos de respuesta, y utilice las mejores prácticas para optimizar el código.

Aplicaciones Checkout MVC desarrolladas con ASP.NET Core.

Si lo haces en Ajax:

Tendrás que considerar los problemas de accesibilidad (búsqueda de accesibilidad web en google) para personas con discapacidad, pero también para navegadores antiguos, aquellos que no tienen JavaScript, bots (como google bot), etc.

Deberá flirtear con la "mejora progresiva", que no es fácil de hacer si nunca trabajó mucho con JavaScript. En resumen, tendrá que hacer que su aplicación funcione con navegadores antiguos y aquellos que no tienen JavaScript (algunos móviles, por ejemplo) o si está deshabilitada.

Pero si el tiempo y el dinero no son un problema, iría con una mejora progresiva.

Pero también considere el "botón Atrás". Odio cuando estoy navegando en un sitio web 100% AJAX que hace que el botón de volverse inútil.

¡Buena suerte!

Tiendo a preferir la lógica del lado del servidor. Mis razones son bastante simples:

No confío en el cliente; esto puede o no ser un verdadero problema, pero es habitual
El lado del servidor reduce el volumen por transacción (aunque sí aumenta el número de transacciones)
El lado del servidor significa que puedo estar bastante seguro de qué lógica está teniendo lugar (no tengo que preocuparme por el motor de Javascript disponible para el navegador del cliente)

Probablemente haya más -y mejores- razones, pero estos son los que están en lo más alto de mi mente en este momento. Si pienso en más, las agregaré o subiré a votar las que se les ocurran antes de hacerlo.

Editado, valya comenta que el uso de la lógica del lado del cliente (usando Ajax / JSON) permite la creación (más fácil) de una API. Esto bien puede ser verdad, pero solo puedo estar medio de acuerdo (por eso aún no voté esa respuesta).

Mi noción de lógica del lado del servidor es la que recupera los datos y los organiza; si lo hago bien, la lógica es el "controlador" (C en MVC). Y esto luego pasa a la ''vista''. Tiendo a usar el controlador para obtener los datos, y luego la ''vista'' trata de presentarla al usuario / cliente. Por lo tanto, no veo que las distinciones cliente / servidor sean necesariamente relevantes para el argumento de crear una API, básicamente: caballos para cursos. :)

... también, como aficionado, reconozco que puedo tener un uso ligeramente torcido de MVC, por lo que estoy dispuesto a permanecer corregido en ese punto. Pero aún mantengo la presentación separada de la lógica. Y esa separación es el punto más en lo que respecta a las API.

Una consideración que no he escuchado mencionar fue el ancho de banda de la red. Para dar un ejemplo específico, una aplicación con la que estuve involucrado fue todo hecho en el lado del servidor y dio como resultado el envío de una página web de 200MB al cliente (era imposible hacer menos sin un gran rediseño importante de un montón de aplicaciones); dando como resultado un tiempo de carga de la página de 2 a 5 minutos.

Cuando volvimos a implementar esto al enviar los datos codificados en JSON del servidor y hacer que JS local generara la página, la principal ventaja fue que los datos enviados se redujeron a 20Mb, lo que dio como resultado:

Tamaño de respuesta HTTP: 200Mb + => 20Mb + (¡ con el ahorro de ancho de banda correspondiente !)
Tiempo para cargar la página: 2-5mins => 20 segundos (10-15 de los cuales son ocupados por la consulta DB que fue optimizada al infierno más).
Tamaño del proceso de IE: 200 MB + => 80 MB +

Eso sí, los últimos 2 puntos se debieron principalmente al hecho de que el lado del servidor tuvo que usar una implementación de árbol de tablas en la mesa, mientras que ir al lado del cliente nos permitió rediseñar la capa de vista para usar una página mucho más liviana. Pero mi punto principal fue el ahorro en el ancho de banda de la red.