JavaScript de front-end puro con API web versus vistas de MVC con ajax

14

Esto fue más una discusión de lo que piensan los pueblos en estos días sobre cómo dividir una aplicación web.

Estoy acostumbrado a crear una aplicación MVC con todas sus vistas y controladores. Normalmente crearía una vista completa y la devolvería al navegador en una solicitud de página completa, a menos que hubiera áreas específicas que no quisiera rellenar de inmediato y luego utilizaría los eventos de carga de la página DOM para llamar al servidor y cargar otras áreas utilizando AJAX.

Además, cuando se trataba de una actualización parcial de la página, llamaría a un método de acción MVC que devolvería el fragmento HTML que luego podría usar para completar partes de la página. Esto sería para áreas en las que no quise ralentizar la carga de la página inicial, o áreas que se ajustaron mejor con las llamadas AJAX. Un ejemplo sería para la paginación de tablas. Si desea pasar a la página siguiente, preferiría que una llamada AJAX obtuviera esa información en lugar de usar una actualización completa de la página. Pero la llamada AJAX todavía devolvería un fragmento HTML.

Mi pregunta es. ¿Mi opinión es arcaica porque provengo de un fondo .net en lugar de un fondo de front-end puro?

Un desarrollador de front-end inteligente con el que trabajo, prefiere hacer más o menos nada en las vistas de MVC y prefiere hacer todo en el front-end. Hasta las llamadas a la API web que pueblan la página. Así que en lugar de llamar a un método de acción MVC, que devuelve HTML, preferiría devolver un objeto estándar y usar javascript para crear todos los elementos de la página.

La forma de desarrollador de front-end significa que cualquier beneficio que normalmente obtengo con la validación del modelo MVC, incluida la validación del lado del cliente, desaparecerá. También significa que cualquier beneficio que obtenga con la creación de las vistas, con plantillas html fuertemente escritas, etc. se habrá ido.

Creo que esto significaría que tendría que escribir la misma validación para la validación de front-end y back-end. El javascript también debería tener muchos métodos para crear todas las diferentes partes del DOM. Por ejemplo, al agregar una nueva fila a una tabla, normalmente usaría la vista parcial MVC para crear la fila y luego la devolvería como parte de la llamada AJAX, que luego se inyecta en la tabla. Al usar una forma de extremo frontal puro, el javascript tomaría un objeto (para, por ejemplo, un producto) para la fila desde la llamada de la API, y luego crearía una fila a partir de ese objeto. Creando cada parte individual de la fila de la tabla.

El sitio web en cuestión tendrá muchas áreas diferentes, desde administración, formularios, búsqueda de productos, etc. Un sitio web que, en mi opinión, no requiere arquitectura en una sola página de solicitud.

¿Qué piensan todos sobre esto?

Estoy interesado en escuchar de los desarrolladores front-end y back-end devs.

    
pregunta eyeballpaul 10.05.2014 - 19:18

5 respuestas

10

También soy algo escéptico de que cada nueva aplicación web deba ser un SPA, pero una cosa que estoy vendiendo al 100% como generalista con la mayor parte de su experiencia en el lado del cliente es que una arquitectura orientada a servicios que entregar los datos en bruto en lugar de HTML al cliente es el camino a seguir, ya sea que esté cargando páginas / vistas creadas previamente desde el servidor y haciendo muchas cosas dinámicas con datos después de cargar la página o compilando casi todo al 100% con JavaScript.

Las razones por las que esto es preferible a un desarrollador del lado del cliente son muy similares a las razones por las que nadie quiere HTML en la base de datos. ¿Qué se supone que debe hacer el desarrollador del lado del cliente cuando quiere recurrir a una tabla, por ejemplo, cuando se les ha entregado HTML? El costo de rendimiento de manejar todo lo que hay en el cliente es trivial en comparación con hacer otra solicitud del servidor para que lo haga por usted. Además, la creación de HTML está bastante bien cubierta en JS-land. Ordenar datos y crear nuevas filas de tablas HTML a partir de ellos es un trabajo bastante trivial para un desarrollador del lado del cliente con experiencia.

¿Y de qué sirve la arquitectura de back-end para un front-end para otro dispositivo que podría necesitar hacer algo exótico como implementar widgets que son 100% de lienzo o una estructura HTML totalmente diferente? ¿Por qué un desarrollador del lado del cliente debe cargar Visual Studio o llamar a la puerta trasera de los desarrolladores para hacer un ajuste estrictamente de presentación?

En cuanto a sus inquietudes acerca de la pérdida de la validación de plantillas fuertemente tipadas, confíe en mí cuando le diga que si está tratando con un desarrollador del lado del cliente competente, no encontrará ninguna herramienta de .NET Framework o Visual Studio que sea más carbón. -a-diamante-a-polvo-aplastante anal sobre HTML bien formado y válido que él / ella es.

Desde la perspectiva de la pila completa, me gusta porque significa que nunca tendré que buscar la lógica de los negocios o las aplicaciones, algunos yutz decidieron caer en la capa de plantillas. Sin mencionar la carga por usuario que quita de sus servidores, mientras que en muchos casos realmente mejora la experiencia de carga para el usuario en navegadores modernos con computadoras modernas.

Creo que también es más fácil razonar acerca de la arquitectura de back-end cuando la has aislado completamente de todas las cosas de presentación. Ya no estás agarrando datos para mezclarlos en algún HTML. Lo está juntando para crear una estructura de datos independiente de la implementación que se relaciona más con el uso general que con lo que se va a hacer con ella en el otro lado. En mi opinión, esto tiende a conducir a una mayor coherencia en la forma en que se manejan las cosas, ya que los datos son ahora un objetivo final en lugar de ser el segundo paso del último paso de un proceso y hay menos oportunidades para que las preocupaciones no relacionadas crucen sus cables.

    
respondido por el Erik Reppen 05.06.2014 - 03:25
5

Ofreceré mi valor subjetivo de 2 centavos (por lo que vale;)). No hay una respuesta correcta o incorrecta y hay muchas consideraciones del mundo real además de sus puntos, por ejemplo:

  • ¿Tiene la experiencia relevante en casa? la construcción de una aplicación orientada al cliente es muy diferente de una aplicación predominantemente dirigida por un servidor con un conjunto de habilidades completamente diferente.
  • ¿Cuánto tiempo desea que tome y qué navegadores necesita admitir? - cuanto más haga en el cliente, más problemas tendrá el navegador; IE8 es doloroso y el rendimiento de JavaScript es bastante bajo, pero hay muchas empresas que ejecutan configuraciones de XP / IE.
  • ¿En qué dispositivos van a estar viendo los usuarios el sitio? El análisis y la ejecución de JavaScript pueden ser rápidos en una versión reciente de Chrome, pero no lo es en un dispositivo móvil más antiguo, especialmente no en una gran cantidad de JavaScript con una carga de lógica empresarial.
  • ¿Qué tan importante es la carga inicial? La plantilla del servidor es más rápida que la plantilla del cliente

Esta lista no es de ninguna manera exhaustiva y suena como un ataque del lado del cliente que no es mi intención, he hecho sitios con un fuerte énfasis en el extremo delantero.

Para mí, todo se reduce a la experiencia del usuario y la reutilización de la API. Para abordar cada uno de estos.

Si va a crear una aplicación u ofrecer una API, tiene mucho sentido utilizar un proyecto de API .Net, esto forma la lógica, la comprobación y la implementación en todas las plataformas. En este escenario, un enfoque completo del lado del cliente puede ser favorable, la API se puede mantener por separado y solo proporciona una interfaz para su aplicación. Puede modificar la lógica y el refactor cómodamente y solo tiene que mantener la interfaz igual. Puede escribir fácilmente diferentes aplicaciones para diferentes medios, todo con el mismo código de fondo.

El argumento más sólido para una solución de front-end pura (en mi opinión) es el de la experiencia del usuario.

¿Ofrece (cuando se consideran todos los inconvenientes) una aplicación de navegador de JavaScript puro ofrece una mejora sustancial en la usabilidad y la experiencia del usuario en un sitio web tradicional?

Al crear sitios que funcionan como aplicaciones nativas; Yo diría que la respuesta es un obvio sí. Sin embargo, la mayoría de los sitios no son tan precisos, por lo que es una cuestión de evaluar si los flujos de trabajo de los usuarios individuales se benefician de una interfaz altamente dinámica.

Tengo una visión bastante pragmática de esto, no es una cosa o una cuestión; Obviamente, JavaScript se jugará bastante bien junto con las tecnologías de Servidor y no tiene que elegir una u otra; cada sitio no es una aplicación web de una sola página, pero no hay nada que le impida utilizar Knockout, backbone y similares en páginas individuales para mejorar las cosas donde se considere necesario.

    
respondido por el SWa 13.05.2014 - 11:28
2

Tengo una relación de amor-odio con aplicaciones pesadas front-end.

Por un lado, me encanta escribir JavaScript y me encanta el navegador como entorno de ejecución.

Por otro lado, ambos se sienten como un auto de carreras de Fórmula 1 con agujeros en el motor. Realmente se reduce a esto: ¿Se puede evitar la duplicación de la lógica empresarial entre C # y JavaScript? Si es así, utilice cualquier método para generar la vista que considere digna. Si está duplicando la lógica empresarial en dos idiomas, es posible que tenga un desarrollador de aplicaciones que solo quiera escribir JavaScript y no vea el panorama completo.

En cuanto a las diferencias técnicas:

Representación parcial y entrega al cliente:

  • Fácil y rápido de implementar
  • Evita que la lógica de negocios de back-end se duplique en la parte delantera
  • Puede resultar en una carga de HTTP mucho más grande para el navegador. No es algo malo en un escritorio con una conexión de alto ancho de banda. Muy mal en un teléfono móvil débil mientras está sentado en un tren de hora punta a 60 mph y otros 1.000 teléfonos móviles se desconectan simultáneamente de una torre celular e intentan reconectarse a la siguiente torre móvil.

Entrega de JSON y representación de una plantilla del lado del cliente:

  • Puede dar como resultado una carga de HTTP más pequeña que HTML, lo que puede hacer que la aplicación parezca más receptiva en las conexiones de red poco confiables o lentas
  • Muchos lenguajes de plantillas de JavaScript están completamente equipados, lo que significa que no necesitamos un backend solo para generar algo de HTML

A veces creo que los nuevos marcos de JavaScript están echando al bebé con el agua de la bañera --- hombre, espero que no me esté convirtiendo en un malhumorado programador de pelea ...

    
respondido por el Greg Burghardt 13.05.2014 - 22:47
0

En mi última aplicación combiné la API REST y el front-end de JavaScript.

Lo que hice fue:

  • Creé una API REST para operaciones CRUD.
  • He creado una aplicación de Javascript que carga HTML predefinido plantillas y se rellena con datos devueltos desde la API REST.

Básicamente, el front-end de JS se comunica con la API REST para operaciones CRUD y rellena los HTML con los datos devueltos o los datos creados, o elimina los datos eliminados o actualiza los datos modificados.

Por lo tanto, tenemos HTML puro, tenemos el procesamiento realizado en el cliente, tenemos menos uso de ancho de banda al no tener que cargar todo el HTML y podemos brindar una experiencia verdaderamente Web 2.0 a los usuarios.

No hago validaciones comerciales en el front-end para la seguridad y la duplicación de código, ya que cualquiera puede cambiar los datos antes de enviarlos al servidor y tenemos que validar los datos en el servidor nuevamente. Por lo tanto, esto sería fácilmente hackeado. Todas las validaciones se realizan en el back-end. Las validaciones en el lado del cliente se realizan solo para los tipos de entrada.

Pros:

  • Facilidad para realizar cambios en HTML debido al hecho de que no se genera por JS;
  • Menor consumo de ancho de banda mediante el uso de ajax y JSON;
  • Menor consumo de procesamiento del servidor, ya que HTML se llena en el lado del cliente;
  • Experiencia de usuario mejorada al utilizar JS para cambiar la pantalla, lo que permite uso de efectos y aumento de la velocidad de reproducción.
  • Mejor uso del protocolo HTTP, usando REST.

Contras:

  • Se deben mantener 2 aplicaciones;
  • Depende del procesamiento del cliente, que puede ser malo debido a un hardware deficiente.

Espero que esto ayude.

Saludos,

    
respondido por el Bruno João 30.05.2014 - 23:07
0

Con respecto al aspecto validation en Web Api - Es posible realizar una "validación de modelo" y responder con una respuesta http de 400 solicitudes incorrectas.

Consulte enlace

    
respondido por el Lijo 31.07.2014 - 05:20

Lea otras preguntas en las etiquetas

Comentarios Recientes

eventos. Tres desafíos de Luis Vorazquez ¿Llamadas más altas? Como mecanografiado, soy un maestro de los depuradores de JavaScript y los desarrolladores de middleware siguen habilidades de la vida real para avanzar en el desarrollo web Scrum impulsado por problemas para aplicaciones web por Mary Jo Winters Modelos de almacenamiento en MVC Views con MSPConcealable Sieve o Tree node Envolviendo RC con When Quotient Pro Las características integradas con el equipo de desarrollo ágil de Salesforce.com tienen como objetivo... Lee mas