¿Qué ventajas le confiere el uso de la representación de páginas del lado del servidor?

19

Estoy desarrollando una aplicación web y actualmente he escrito todo el sitio web en html / js / css y en el backend tengo servlets que alojan algunos servicios RESTFUL. Toda la lógica de presentación se realiza obteniendo objetos json y modificando la vista a través de javascript.

La aplicación es esencialmente un motor de búsqueda, pero tendrá cuentas de usuario con diferentes roles.

He estado investigando algunos marcos como Play y Spring. Soy bastante nuevo en el desarrollo web, así que me preguntaba qué ventajas proporcionaría el procesamiento de páginas del lado del servidor.

¿Es: velocidad? ¿Desarrollo y flujo de trabajo más fáciles? ¿Acceso a bibliotecas existentes? ¿Más? Todas las anteriores?

javascript web-applications frameworks

— usuario1303881
fuente

44

La seguridad es grande. En particular cuando la aplicación es dinámica y necesita comunicarse con una base de datos.

— Oded

2

@Oded: ¿por qué es más fácil hacer la seguridad cuando renderiza la página en comparación con la API? Siempre he pensado que lo que tienes que programar es equivalente de cualquier manera, pero es más fácil (al menos para mí) psicológicamente recordar no confiar en el cliente al hacer una API. Lo pregunto porque si estoy pasando por alto algo que realmente quiero saber.

— psr

1

@psr Puede que no se refiera tanto a la seguridad de los datos como a la seguridad del usuario (por ejemplo, explotaciones de MITM). Solo una suposición sin embargo.

— maple_shaft

1

@psr - De acuerdo. Sin embargo, ayer respondí una pregunta en la que el OP tenía la cadena de conexión incrustada en JS ...

— Finalizado el

1

@maple_shaft: MITM es algo en lo que pensar, pero una vez más, no estoy seguro de por qué hace una diferencia para API versus HTML generado por el servidor. Supongo que una API es más conveniente para programar, por lo que sería una grieta marginalmente más fácil, pero dudo que eso sea lo que quieres decir.

— psr

16

Representación HTML del lado del servidor:

Representación más rápida del navegador
El almacenamiento en caché de página es posible como un impulso de rendimiento rápido y sucio
Para las aplicaciones "estándar", muchas características de la interfaz de usuario están preconstruidas
A veces se considera más estable porque los componentes suelen estar sujetos a validación en tiempo de compilación
Se apoya en la experiencia del backend
A veces más rápido de desarrollar *

* Cuando los requisitos de IU se ajustan bien al marco.

Representación HTML del lado del cliente:

Menor uso de ancho de banda
Procesamiento inicial más lento de la página. Puede que ni siquiera se note en los navegadores de escritorio modernos. Si necesita soportar IE6-7, o muchos navegadores móviles (el webkit móvil no es malo) puede encontrar cuellos de botella.
Crear API primero significa que el cliente puede ser fácilmente una aplicación propietaria, un cliente ligero, otro servicio web, etc.
Se apoya en la experiencia de JS
A veces más rápido de desarrollar **

** Cuando la interfaz de usuario es en gran medida personalizada, con interacciones más interesantes. Además, encuentro que la codificación en el navegador con código interpretado es notablemente más rápida que esperar compilaciones y reinicios del servidor.

También puede considerar un modelo híbrido con una implementación de back-end ligera que utiliza un sistema de plantillas front-end / back-end como el bigote .

— peteorpeter
fuente

1

Whoah, se olvidó por completo de las oportunidades de almacenamiento en caché!

— Michael K

"Para las aplicaciones" estándar ", muchas características de la interfaz de usuario están preconstruidas" Eso es irrelevante, tanto el servidor como el cliente lo tienen.

— Raynos

@Raynos No había mencionado el uso de un marco del lado del cliente , pero si está usando uno, ese es un buen punto.

— peteorpeter 05 de

1

Gracias, esta es principalmente la respuesta que estaba buscando. No he hecho demasiado con los marcos del lado del cliente, pero estaba investigando sobre dust.js según la elección de LinkedIn. Sé que el bigote es una alternativa, pero lo investigaré más. Probablemente haré algún tipo de híbrido, principalmente me gustaría llevar las cosas al lado del servidor si eso puede mejorar el rendimiento. Gracias de nuevo.

— user1303881

Realmente no consideraría nada como una "representación HTML del lado del cliente" como una ventaja. "A veces más rápido de desarrollar" sale por la ventana una vez más de lo que se consideran los navegadores de última generación (IE 8, etc.).

— nulo

3

generación HTML del lado del servidor:

más fácil de depurar;
sin problemas con la compatibilidad del navegador;
con la generación clásica del lado del servidor de página completa es más difícil almacenar en caché HTML, incluso si tiene partes invariables grandes; (la solución es buscar fragmentos HTML a través de llamadas AJAX);
no aprovechar los servidores proxy de almacenamiento en caché y los CDN para HTML dinámico;

generación HTML del lado del cliente:

más difícil de depurar;
algunos problemas con navegadores obsoletos;
sin problemas de almacenamiento en caché de plantillas HTML del lado del cliente;
aprovechando el almacenamiento en caché de proxies y CDN para plantillas HTML y código JS;
uso de red mucho menor;

Tenga en cuenta que la generación del lado del cliente es la forma en que se realiza en el caso de sitios móviles exitosos, ya que aparentemente es mucho más eficiente con los navegadores modernos (los navegadores basados en WebKit tienen alrededor del 70-80% del mercado móvil).

LinkedIn tiene un artículo sobre las ventajas del enfoque del lado del cliente utilizando dust.js como ejemplo: "Dejar JSP en el polvo: mover LinkedIn a las plantillas del lado del cliente dust.js"

— vartec
fuente

1

+1 En los teléfonos inteligentes modernos (que usan principalmente webkit móvil), no es probable que JS tenga un cuello de botella, mientras que el ancho de banda de la red celular sí lo es .

— peteorpeter 05 de

1

Depende de cuáles sean sus requisitos. Si necesita una solución de alto rendimiento y baja latencia que depende de muchas tareas pequeñas, puede optar por una estructura similar a la que describe. Sin embargo, las soluciones más comunes, en Java, PHP y C #, no tienen esto por defecto.

La mayoría de las aplicaciones web dependen en gran medida de las bases de datos, la mayoría de ellas tanto que las páginas no se pueden procesar sin al menos una llamada. Obviamente, no desea exponer su base de datos públicamente, por varias razones:

Seguridad (como menciona Oded ): ¡definitivamente no desea exponer su red públicamente! Idealmente, la única interfaz a sus sistemas desde el exterior debería ser https a su servidor.
Facilidad de desarrollo: realmente, realmente , realmente no desea escribir SQL en Javascript, y los lenguajes diseñados para la presentación web no funcionan bien con los RDB. No tienen concepto de estado, por ejemplo.

Entonces, cuando necesita una base de datos, utiliza lenguajes que funcionan bien con ellos, como Java, C #, PHP, etc. La forma más fácil de generar una página es la siguiente: utiliza un lenguaje de plantillas (más conocido como PHP, pero JSP y ASP son otros dos lenguajes muy comunes) para construir la página. El lenguaje proporciona construcciones que llaman a otros módulos. En PHP, esto es comúnmente en la página o en otro archivo PHP, utilizando el patrón MVC. En JSP utiliza scriptlets o el lenguaje de expresión JSP. Estos otros módulos pueden hacer el trabajo pesado de conectarse a la base de datos, realizar la lógica y devolver valores a su capa de vista. El resultado final es una página HTML generada, representada en el servidor y enviada al cliente.

Cuando su base de datos está en la misma red que su procesador de página, también obtiene un mejor rendimiento. El cliente solo tiene que hacer una solicitud y recibe una página; puede que tenga que hacer entre 10 y 15 solicitudes de base de datos antes de tener toda la información que necesita el usuario. Una latencia de milisegundos en su red sería de segundos a minutos si el cliente tuviera que hacerlos todos.

Cuando los sistemas crecen, la separación de las preocupaciones y las competencias básicas se vuelve crucial. HTML es bueno para mostrar. Javascript es bueno para contenido dinámico. SQL es excelente para consultar una base de datos, y otros lenguajes son buenos para la lógica empresarial. Nuestro trabajo como desarrolladores es utilizar todas las herramientas disponibles para construir un sistema que se pueda mantener. La facilidad de desarrollo es una gran parte de un buen sistema. En mi opinión, es casi tan importante como el rendimiento y la usabilidad. Los grandes sistemas evolucionan con el tiempo. Los sistemas pobres se escribieron mal desde el principio y nunca se mejoraron.

— Michael K
fuente

you can't write SQL in Javascript ¡¿De Verdad?! ¿Alguna vez has mirado a preguntas StackOverflow para Javascript? Me rogaría diferir desafortunadamente. De acuerdo, es lo peor que podrías hacer en el código del cliente, pero ...

— maple_shaft

... también me olvidé de Node.JS, pero ese es el servidor JS, que es un animal completamente diferente.

— maple_shaft

Aparentemente puedes - ¡TIL! Solo ... wow, sin embargo. Sin embargo, ¡habla sobre el abuso del idioma!

— Michael K

2

La interfaz REST es cómo el cliente accede actualmente a los datos de la base de datos a través de objetos json. No expone todo y esta aplicación es parte de una red empresarial privada. Una ventaja de las interfaces es la capacidad de otras aplicaciones en la empresa de aprovechar cualquier servicio que deseen. Desde una perspectiva de desarrollo, puedo dejar que los desarrolladores front-end hagan lo que quieran en html / js / css y luego simplemente pueden hacer ping en la interfaz RESTful diseñada por los desarrolladores de Java. Sin embargo, la mayoría de nosotros tenemos un conjunto combinado de habilidades y esa división puede no ser necesaria.

— user1303881

3

-1: @MichaelK: estás discutiendo con un hombre de paja que has imaginado, pero que no tiene absolutamente nada que ver con la vida real. RESTful usa HTTP. Nadie necesita escribir SQL en JS, para eso está la interfaz RESTful. Tampoco RESTful significa que hay una asignación 1 a 1 con consultas DB. Su respuesta podría haber sido válida en la década de 1990, pero ahora estamos en 2012.

— vartec

0

Los clientes móviles suelen tener limitaciones de potencia, ancho de banda y memoria. Probablemente sea mejor renderizar páginas para ellos en el servidor.

Para los clientes de escritorio, puede considerar enviar js + json para representar la página en el cliente, hacerla actualizable dinámicamente, etc.

— 9000
fuente

En la práctica, sin embargo, lo contrario es a menudo cierto. El proyecto jQuery Mobile, de hecho, se basa completamente en la idea del renderizado del lado del cliente.

— Puntiagudo

@Pointy: sí, esto puede ser al revés. Uno debería probar cómo se comportan páginas particulares en clientes particulares. También puede ser útil para el usuario proporcionar un enlace a una alternativa (como los enlaces de versión 'móvil' y 'escritorio').

— 9000

Hoy en día, los dispositivos móviles se caracterizan mucho más por una alta latencia que un bajo ancho de banda o potencia de procesamiento. En el proyecto en el que trabajé recientemente, estábamos más preocupados por el tamaño de la página que por la velocidad de representación: los teléfonos modernos son bastante buenos.

— Michael K

@Pointy, el proyecto jQuery Mobile también es una gran cantidad de código horrible que no debe usarse. Popularidad! == value

— Raynos

@Raynos En realidad estamos usando Jquery Mobile, con bastante éxito también. ¿Sabes algo que nosotros no? ;)

— Michael K

0

Una gran ventaja de la representación del lado del servidor es la accesibilidad: las aplicaciones basadas en JavaScript siguen siendo un gran problema para las personas que no ven. Eso y hay un ciego llamado "googlebot" a quien querrás atender. Tampoco hace javascript tan bien.

— Wyatt Barnett
fuente

Buen punto, aunque esta aplicación no requiere SEO porque es privada, también estoy desarrollando algunas aplicaciones personales y eso es una consideración en ese campo.

— user1303881

Googlebot interpretar JS / AJAX desde hace bastante tiempo: searchenginewatch.com/article/2122137/...

— VarTec

@vartec: Creo que la sesión clave en ese artículo es "ahora puede leer y comprender ciertos comentarios dinámicos implementados a través de AJAX y JavaScript". Mi sospecha es que cubre disqus y facebook, pero no su configuración personalizada de ajax.

— Wyatt Barnett