JavaScript front-end puro con API web frente a vistas MVC con ajax

Esto fue más una discusión sobre lo que piensan las personas 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 pasaría esto al navegador en una solicitud de página completa, a menos que hubiera áreas específicas que no quisiera llenar de inmediato y luego usaría eventos de carga de página DOM para llamar al servidor para cargar otras áreas usando AJAX.

Además, cuando se trataba de la 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 que no quería ralentizar la carga de la página inicial, o áreas que se ajustaban mejor con las llamadas AJAX. Un ejemplo sería para paginación de tabla. Si desea pasar a la página siguiente, preferiría que una llamada AJAX recibiera esa información en lugar de utilizar una actualización completa de la página. Pero la llamada AJAX aún devolvería un fragmento HTML.

Mi pregunta es. ¿Mis pensamientos sobre esto son arcaicos porque vengo de un fondo .net en lugar de un fondo frontal puro?

Un desarrollador front-end inteligente con el que trabajo, prefiere no 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. Entonces, 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 front-end significa que cualquier beneficio que normalmente obtengo con la validación del modelo MVC, incluida la validación del lado del cliente, se habrá ido. También significa que los beneficios que obtengo al crear las vistas, con plantillas html fuertemente tipadas, etc., desaparecerán.

Creo que esto significaría que necesitaría escribir la misma validación para la validación frontal y posterior. El Javascript también necesitarí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 front end pura, el javascript tomaría un objeto (por ejemplo, un producto) para la fila de la llamada a la API y luego crearía una fila a partir de ese objeto. Crear 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 no creo que requiera ser diseñado en una sola página.

¿Qué piensan todos sobre esto?

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

También estoy un poco escéptico de que cada nueva aplicación web necesite ser un SPA, pero una cosa en la que estoy 100% convencido como generalista con la mayor parte de su experiencia en el lado del cliente es que una arquitectura orientada al servicio que se entrega en bruto los datos en lugar de HTML para el cliente son el camino a seguir si está cargando páginas / vistas preconstruidas desde el servidor y está haciendo muchas cosas dinámicas con datos después de cargar la página o construyendo 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 quieren recurrir a una tabla, por ejemplo, cuando se les ha entregado HTML? El costo de rendimiento de manejar todo eso en el cliente es trivial en comparación con hacer otra solicitud de servidor para que lo haga por usted. Además, la construcción de HTML está bastante bien cubierta en JS-land. Ordenar datos y construir nuevas filas de tablas HTML a partir de ellos es un trabajo bastante trivial para un desarrollador experimentado del lado del cliente.

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

En cuanto a sus preocupaciones sobre 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 competente del lado del cliente, no encontrará un marco .NET o una herramienta de estudio visual que sea más útil Diamante a polvo-analmente aplastante 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 comercial o de la aplicación, y algunos decidieron caer en la capa de plantillas. Sin mencionar la carga por usuario que despega de sus servidores, mientras que en muchos casos mejora la experiencia de carga para el usuario en navegadores modernos con computadoras modernas.

Creo que también es más fácil razonar sobre la arquitectura de back-end cuando la has aislado por completo de todas las presentaciones. Ya no estás tomando datos para combinarlos en HTML. Lo está uniendo para crear una estructura de datos independiente de la implementación que se ocupa más del uso general que de lo que se hará con el otro lado. OMI, eso tiende a conducir a una mayor coherencia en la forma en que se manejan las cosas, ya que los datos ahora son un objetivo final en lugar del segundo al último paso de un proceso y hay menos oportunidades para que las preocupaciones no relacionadas se crucen.

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

• ¿Tienes la experiencia relevante en casa? la creación de una aplicación dirigida por el cliente es muy diferente a una dirigida principalmente por el servidor con un conjunto de habilidades completamente diferente.
• ¿Cuánto tiempo desea que demore y qué navegadores necesita admitir? - cuanto más hagas en el cliente, más problemas tendrás con el navegador; IE8 es doloroso y el rendimiento de JavaScript es bastante pobre, pero hay muchas empresas que ejecutan configuraciones de XP / IE.
• ¿En qué dispositivos van a ver sus 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 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 exhaustiva y suena como un golpe del lado del cliente, lo cual no es mi intención, he creado sitios con un gran énfasis en el front-end.

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 usar un proyecto de API .Net, esto forma la plataforma multiplataforma de lógica, verificación e implementación. 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 refactorizar 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 fuerte para una solución front end pura (en mi opinión) es la de la experiencia del usuario.

¿Al considerar todas las desventajas, una aplicación de navegador 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 limpios, por lo que se trata 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 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 lo detenga con Knockout, backbone y similares en páginas individuales para mejorar las cosas donde se considere necesario.

Tengo una relación de amor y odio con aplicaciones pesadas de 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: ¿Puede evitar la duplicación de la lógica empresarial entre C # y JavaScript? Si es así, use cualquier método para generar la vista que considere digna. Si está duplicando la lógica de negocios en dos idiomas, es posible que tenga un desarrollador front-end que solo quiera escribir JavaScript y no vea el panorama completo.

En cuanto a las diferencias técnicas:

Renderizar un parcial y entregarlo al cliente:

• Fácil y rápido de implementar.
• Evita que la lógica empresarial del backend se duplique en el front-end
• Puede resultar en una carga HTTP mucho mayor para el navegador. No es algo malo en un escritorio con una conexión de ancho de banda alto. Muy mal en un teléfono móvil débil mientras estás sentado en un tren de la hora pico que baja por la vía a 60 mph y otros 1,000 teléfonos móviles se desconectan simultáneamente de una torre celular e intentan volver a conectarse a la siguiente torre celular.

Entregando JSON y renderizando 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 a través de conexiones de red lentas o poco confiables
• Muchos lenguajes de plantillas JavaScript tienen todas las funciones, lo que significa que no necesitamos un backend solo para generar HTML

A veces creo que los nuevos marcos de JavaScript están tirando al bebé con el agua del baño --- hombre, espero no convertirme en un malhumorado programador de cascarrabias ...

En mi última aplicación, combiné REST api y JavaScript front-end.

Lo que hice fue:

• Creé una API REST para operaciones CRUD.
• Creé una aplicación Javascript que carga plantillas HTML predefinidas y se llena con datos devueltos por la API REST.

Básicamente, el front-end de JS se comunica con la API REST para operaciones CRUD y llena los HTML con los datos devueltos o 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 por seguridad y 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 pirateado. 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 a que JS no lo genera;
• Menor consumo de ancho de banda utilizando ajax y JSON;
• Menor consumo de procesamiento del servidor, ya que el HTML se completa en el lado del cliente;
• Se mejoró la experiencia del usuario al usar JS para cambiar la pantalla, permitiendo el uso de efectos y aumentando la velocidad de renderizado.
• Mejor uso del protocolo HTTP, utilizando REST.

Contras:

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

Espero que esto ayude.

Saludos,

Con respecto al validationaspecto en Web Api: es posible hacer una "validación del modelo" y responder con una respuesta HTTP de 400 solicitudes incorrectas.

Consulte /programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285