¿Está creando aplicaciones web en el lado del servidor frente al lado del cliente frente al híbrido? [cerrado]

27

Actualmente existen múltiples enfoques para crear aplicaciones web:

1. Solo del lado del servidor

Este es un enfoque clásico en el que representa páginas en el servidor mediante un marco web como Ruby on Rails, Django, Express, Play! Marco y etc.

Flujo de trabajo típico : cree toda su lógica empresarial, modelos y plantillas de vista en el servidor en el marco de su elección.

2. API del lado del cliente + REST

Hace relativamente poco tiempo, la comunidad web en su conjunto comenzó a construir aplicaciones del lado del cliente en Angular, Backbone, Ember y algunas docenas de otros marcos JavaScript MV *. Y ahora también tenemos React.js unirse a la fiesta.

ACTUALIZACIÓN : No hay malentendidos. Lo que quise decir solo con el lado del cliente es la separación completa de las preocupaciones. Tiene un servidor API REST y una aplicación del lado del cliente que se comunica con ese servidor. Dependiendo de su caso de uso, lo más probable es que nunca tenga una verdadera aplicación solo del lado del cliente que no se conecte a un back-end para autenticación o persistencia de datos.

Flujo de trabajo típico : pase horas decidiendo Angular vs Backbone vs Ember vs X. Luego construye sus rutas, modelos, vistas, controladores en el cliente. Una vez que haya terminado, ahora cree modelos, controladores, rutas en el servidor. En cierto modo, estás haciendo el doble de trabajo.

3. Híbrido

No sé mucho sobre el uso de este enfoque, pero si tuviera que adivinar, representaría sus vistas (Vista del marco MVC) en el servidor. Como resultado, obtienes soporte SEO y cargas de página más rápidas.

En el frente híbrido hay un reproductor de airbnb que supuestamente combina backbone y express.

Eric Florenzo ha publicado en su blog hoy: Reaccionar: Finalmente, una gran pila web de servidor / cliente .

La cantidad de formas de crear aplicaciones web es abrumadora. Y para alguien que está aprendiendo desarrollo web, esto puede convertirse en un problema. ¿Cómo se decide qué enfoque usar para construir su próxima aplicación?

javascript web-development Clasificada R
fuente
1
"Solo del lado del cliente: ... Una vez que haya terminado, ahora cree modelos, controladores, rutas en el servidor". Esto no analiza.
user16764
@ user16764 actualizó mi pregunta.
Calificación R
Un par de enlaces interesantes: kreuzwerker.de/en/blog/posts/… , branchandbound.net/blog/web/2012/11/…
dagnelies

Respuestas:

13

Creo que ha entendido totalmente mal el "lado del cliente solamente".

En primer lugar, debe etiquetarse "Cliente centrado" Todo este punto de marcos como Angular es que las partes "VC" de MVC se implementan completamente en el navegador en Javascript. La lógica de nivel superior "M" de la parte "M" - el Modelo - se implementa en el navegador y la lógica de "CRUD" de nivel inferior se implementa en el servidor.

La lógica de negocios se desarrolla una vez. La lógica de vista se desarrolla una vez. La lógica de control se desarrolla una vez, todo en el marco de elección de Javascript. La lógica de acceso a datos también se desarrolla solo una vez, pero esta vez en cualquier marco RESTy o SOAPy que elija en el lado del servidor.

En casos extremos, puede implementar el Modelo completamente en el cliente, si es aceptable acceder a los datos desde un solo navegador en una máquina, y hacer que los datos se eliminen cada vez que se selecciona la opción "Borrar cookies".

James Anderson
fuente
Es realmente difícil no desarrollar al menos parte de la lógica empresarial dos veces. Para una buena experiencia de usuario, debe asegurarse de que el usuario ingrese su correo electrónico para continuar. Pero no puede confiar en el cliente, por lo que también debe implementar la regla en el servidor. Al menos realmente espero que no estés diciendo implementar la lógica de negocios en JS en el cliente.
Andy
@ Andy, ese es exactamente mi punto. Cuando construí una aplicación Ember, la validación básica del formulario tenía que hacerse en el cliente, pero también tenía que hacerse en el servidor. Me metí en serios problemas una vez por no validar mis datos en el servidor y confiar completamente en el cliente.
Calificación R
Andy et all: echa un vistazo a los documentos de google. Además de cargar el documento, la hoja de cálculo, etc. desde el servidor, guardarlo al final y realizar copias de seguridad ocasionales entre todo lo demás en su navegador. El sitio de Google Docs solo actúa como un almacén de datos y un servidor de autenticación.
James Anderson el
3
@JamesAnderson Google Docs es bastante diferente de decir una tienda en línea. Está editando su propio documento, es solo una gota de datos que guardan sin preocuparse realmente por lo que significan los datos. ¿Pero realmente crees que la validación del pedido debe hacerse SOLO en el cliente? Solo está pidiendo que las personas se den productos gratuitos si así es como se crea una aplicación de este tipo. Parece que también está asumiendo que Google, de hecho, no está haciendo ninguna validación de datos en el servidor. Realmente no hay forma de que sepamos qué está pasando.
Andy
9

La respuesta a la pregunta es que depende de los requisitos. Una mirada al menos superficial a la historia del desarrollo de la "web" indica una cultura vaquera en la que a menudo se pasa por alto hablar con las partes interesadas, los clientes y la recopilación de requisitos.

Tuve la suerte de asistir a una charla hace algunos años donde escuché algo que realmente me quedó grabado: "eliges el diseño para cumplir con los requisitos, no los requisitos para cumplir con el diseño". Entonces, cuando se enfrenta a una pregunta como esta, debe averiguar qué es lo que realmente necesitan las personas que le piden que cree este software.

Su trabajo es explicar los pros y los contras detrás de cada enfoque.

RibaldEddie
fuente
1
Gracias. Lo que estás diciendo tiene sentido. Esperaba que hubiera una "bala de plata", una verdadera forma de hacer las cosas. Comencé con un marco web de Python llamado Django en 2011. Poco después hubo un gran impulso hacia los marcos MV * del lado del cliente como Backbone, Angular, Ember. Y de repente, la forma en que Rails y Django construyen aplicaciones web se ha quedado obsoleta. Pero hoy parece que estamos dando un paso atrás y mezclamos el lado del cliente con el lado del servidor una vez más para lograr un mejor rendimiento.
Calificación R
Lamentablemente, no, no hay bala de plata. :). Sin embargo, el truco es tener una comprensión suficiente de cómo encajan las piezas para determinar los mejores resultados para la tarea en cuestión, y también para apoyar una cultura de refactorización despiadada para que siempre pueda cambiar las cosas si su dirección inicial no fue fructífera.
RibaldEddie
1
Esto está bien y todos, pero a veces ambos enfoques son viables y en este caso necesita algo más que un requisito para tomar una decisión.
Ced
5

Creo que uno de los puntos clave de los enfoques y marcos más nuevos es que hay menos acoplamiento entre las tecnologías front-end y las tecnologías back-end.

La idea es que puede usar cualquier marco en el cliente y extraer datos y / o vistas de cualquier número de fuentes, independientemente del marco del lado del servidor.

Esto nos permite elegir las mejores herramientas para hacer el trabajo y nuestras elecciones pueden evolucionar independientemente.

Es cierto que no he usado Angular o Backbone, por lo que no puedo hacer ninguna recomendación con experiencia. Mi pila base actual consiste en el mvc más delgado del lado del servidor o los servicios relajantes que puedo encontrar. Principalmente entregando plantillas y datos. Los datos se procesan y / o los datos posteriores se recuperan del lado del cliente utilizando principalmente javascript, jquery y css.

Comienzo aquí y construyo sobre él donde necesito. Los beneficios de este enfoque son evidentes cuando piensa en admitir múltiples plataformas de clientes: navegador, móvil, etc. Si necesita una representación específica del cliente, no debería necesitar hacer cambios masivos en el lado del servidor.

crad
fuente