javascript - que - server side rendering react

Client Side HTML MVC Rendering vs Server Side Rending a través de NodeJS

Question

Estamos buscando opciones en nuestro equipo para decidir entre un enfoque de MVC del lado del cliente basado en Angular y un enfoque de procesamiento del lado del servidor NodeJS / ExpressJS del lado del servidor.

Nuestra aplicación Angular se descarga como un index.html y realiza solicitudes XHR para completar la página. Como necesitamos que la página esté pre-renderizada, hemos utilizado PhantomJS para guardar una copia de cada página cuando el contenido cambia a una ubicación en el servidor. Esto permite soporte para SEO.

¿Hay ejemplos de aplicaciones de backbone de página completa o aplicaciones angulares que las personas puedan señalar para que veamos si otros están haciendo esto?

Alternativamente, están los ejemplos de aplicaciones renderizadas del lado del servidor NodeJS que podemos ver en la naturaleza.

Por último, ¿alguien tiene opiniones sobre este tipo de arquitectura?

Answer 1

Actualmente estamos probando este enfoque loco: tenemos la aplicación angularJS que se ejecuta en el cliente. Cuando detectamos Googlebot como agente, PhantomJS instancia de PhantomJS y respondemos al rastreador con el resultado de eso. La parte difícil es saber cuándo se completó la carga de la aplicación cliente para que pueda seleccionarla y devolverla. Si lo haría antes de que se cargue la aplicación JS del lado del cliente, el rastreador no recuperará muchos datos, principalmente solo el index.html.

La implementación simple se puede encontrar aquí: http://pastebin.com/N3w2iyr8

ACTUALIZACIÓN: En el momento en que escribí la respuesta original, no existía nada como prerendr.io, pero puedo señalarlo now .

Answer 2

Con node.js en el servidor, en principio puede usar el mismo código para representar en el cliente y en el servidor. Los marcos que implementan este enfoque son Meteor y Derby , también realizan una sincronización transparente de los modelos de datos entre el cliente y el servidor. Sin embargo, se considera que ambos están en alfa, pero parecen funcionar bastante bien.

Mientras tanto, tanto la representación del lado del cliente como del servidor tienen sus pros y sus contras:

• La representación del lado del cliente tiene la desventaja de que la carga de la página inicial toma mucho tiempo, pero una vez que se cargan todos los recursos, el usuario puede navegar el sitio sin problemas. Es posible que desee minimizar el número de llamadas Ajax y / o usar un caché del lado del cliente (por ejemplo, datos de caché en el controlador Angular.js).
• La representación del lado del servidor proporciona una carga de página inicial rápida y es buena para SEO, pero cada vez que el usuario navega, toda la página se queda en blanco por un segundo mientras carga la nueva URL.

Por lo tanto, todo depende de si desea una carga inicial rápida de la página pero no espera que los usuarios se queden tanto tiempo (luego use la representación del lado del servidor) o no es tan importante que la página se cargue rápidamente (como en Gmail) pero los usuarios navegue durante mucho tiempo (luego use la representación del lado del cliente).

Answer 3

Mi solución para hacer que la Aplicación en Angular sea rastreable por Google. Utilizado en aisel.co

1. Instantáneas manejadas por https://github.com/localnerve/html-snapshots

2. Añadir regla a tu .htaccess

   RewriteCond %{QUERY_STRING} ^_escaped_fragment_=(.*)$
   RewriteCond %{REQUEST_URI} !^/snapshots/views/ [NC]
   RewriteRule ^(.*)/?$ /snapshots/views/%1 [L]

3. Cree el script node.js para las instantáneas y ejecútelo en el terminal: node snapshots.js

   var htmlSnapshots = require(''html-snapshots'');
       var result = htmlSnapshots.run({
       input: "array",
       source: [
               "http://aisel.dev/#!/",
               "http://aisel.dev/#!/contact/",
               "http://aisel.dev/#!/page/about-aisel"
       ],
       outputDir: "web/snapshots",
       outputDirClean: true,
       selector: ".navbar-header",
       timeout: 10000
   }, function(err, snapshotsCompleted) {
       var fs = require(''fs'');
       fs.rename(''web/snapshots/#!'', ''web/snapshots/views'', function(err) {
           if ( err ) console.log(''ERROR: '' + err);
       });
   });

4. Asegúrate de que todo funciona con rizo, escribe en terminal

   curl http://aisel.dev/ /? _ escaped_fragment _ / = / page / about-aisel / esto debería mostrar el contenido de la imagen ... / www / aisel.dev / public / web / snapshots / views / page / about-aisel /index.html

No sobre la directiva para goggle y otros rastreadores. Tu aplicación debe contener meta regla en la cabeza:

    <meta name="fragment" content="!">

Términos completos de google aquí: https://developers.google.com/webmasters/ajax-crawling/docs/specification

Answer 4

He trabajado tanto en la mayoría de las aplicaciones de representación del servidor como en la mayoría de las aplicaciones de representación del cliente. Cada tipo tiene sus propias ventajas y desventajas. Sin embargo, la idea de que tiene que elegir entre uno u otro es una falsa dicotomía. Si tiene los recursos, puede combinar ambos para obtener lo mejor de ambos mundos.

Veo 4 desafíos principales con marcos puramente del lado del cliente:

• SEO y Analytics
• Almacenamiento en caché
• Memoria
• Estado latente

SEO

Debido a que está utilizando Node.JS, el problema de SEO se puede mitigar simplemente usando el marco del lado del cliente en el servidor para generar páginas estáticas para googlebot y compañía. Recientemente, Google ha creado una buena API de análisis para aplicaciones de una sola página, pero será un poco más de trabajo que simplemente agregar un par de líneas al final de su plantilla maestra.

Almacenamiento en caché

El almacenamiento en caché es una forma realmente importante de acelerar cualquier aplicación web. Para pequeñas cantidades de datos, puede ser más rápido almacenar en caché los datos del cliente en la memoria o en localStorage, pero el espacio de almacenamiento es muy limitado (actualmente de aproximadamente 5 MB). Además, la invalidación de caché es bastante difícil de hacer en localStorage.

Memoria

La memoria es algo que he pagado caro por pasar por alto. Antes de darme cuenta, accidentalmente había creado una aplicación que ocupa más de 200 MB de RAM. Podría ser capaz de reducir eso a la mitad con optimizaciones, pero dudo que hubiera necesitado más de 20 MB si lo hubiera renderizado todo en el servidor.

Estado latente

La latencia también es fácil de perder. Drupal, por ejemplo, ejecuta entre 50 y 100 consultas SQL para cada página. Cuando el servidor de la base de datos está justo al lado del servidor de la aplicación, no tiene que preocuparse por la latencia y todas esas consultas se pueden ejecutar en menos de un par de cientos de milisegundos. Su aplicación del lado del cliente usualmente tomará cien milisegundos para hacer una sola solicitud AJAX. Esto significa que debe pasar mucho tiempo diseñando la API del lado del servidor para minimizar estos viajes de ida y vuelta, pero en ese punto el servidor ya tiene todos los datos que necesita para generar el HTML también. Tener una aplicación del lado del cliente que se comunica con una interfaz correctamente REST puede resultar glacialmente lento si no se tiene cuidado.

37 Signals recientemente bloguearon sobre la arquitectura híbrida cliente / servidor que implementaron para la nueva versión de Basecamp. Este enfoque híbrido utiliza el servidor para representar HTML pero aprovecha algo como PJAX en el cliente para deshacerse de las actualizaciones de la página completa. El efecto es realmente rápido y es lo que recomiendo.