Representación del Lado del Servidor. SSR con NuxtJS. Framework JavaScript
INTRODUCCIÓN
Representación del Lado del Servidor. SSR con NuxtJS. Framework JavaScript. Hay ventajas y desventajas en el uso del procesamiento de la Representación lado del servidor, pero la principal pregunta que tuve al encontrar la posibilidad de usar el lado del cliente o del lado del servidor fue:
Cuándo usar la representación del lado del servidor?
En este post, veremos los momentos dentro del desarrollo frontend donde podremos optar por utilizar La Representación del lado del Servidor (SSR) usando tecnologías modernas y populares, adicionando también las múltiples ventajas y sus pocas desventajas.
¿Qué Encontramos Cuando Usamos La Representación Del Lado Del Servidor?
SEO
Los rastreadores de motores de búsqueda, como Google, Bing y otros, deben tener claro qué encontrarán en su contenido, porque los rastreadores no admiten JavaScript. Cuando utilizamos una aplicación del lado del cliente, como el nombre ya dice, el contenido se carga casi siempre después de la disponibilidad en el navegador, lo que dificulta identificar el contenido a través de su archivo HTML e indexar su página.
Otro problema que se presenta es que las redes sociales tampoco pueden identificar el contenido cuando intentan acceder a su página para recopilar la información y montar los datos para compartir, y esto también es malo para los sitios que necesitan esta interacción.
La solución es que usar SSR antes de servir al navegador ocurre en su aplicación un proceso para montar un documento HTML que coincida con la solicitud, si necesita datos de su API, el servidor hará una solicitud y manejará la respuesta hasta insertarla en HTML antes de enviarlo al cliente. Este método rastreadores también recibe este contenido completo, por lo que es más fácil de analizar e indexar. Lo mismo ocurre con las redes sociales.
Por lo tanto, si su aplicación necesita este tipo de enfoque, deberá usar la representación del lado del servidor, que entre nosotros es la razón más importante y más importante a la hora de decidir si se utiliza el procesamiento en el servidor.
Rendimiento (Sí y No)
Cuando un usuario solicita una página, no tiene que esperar a que se cargue JavaScript antes de que se muestre el contenido, ya que los componentes ya se procesaron en el servidor y se convirtieron en etiquetas HTML, lo cual es bueno para los usuarios y dispositivos lentos de Internet.
Esto da como resultado una mejor experiencia de usuario, pero la interactividad de la aplicación solo se producirá cuando JavaScript y Vue estén cargados correctamente.
El NO en el título de esta sección es que, incluso si a veces es discreto con SSR, le da más trabajo al servidor, y dependiendo de lo que necesite al presentar la respuesta HTTP al cliente, le llevará un poco más de tiempo.
La causa de este retraso a veces se debe al procesamiento intensivo que ocurre en el servidor en cada solicitud o si su aplicación requiere datos de una API externa, donde el servidor tendrá que esperar a que la respuesta sea capaz de procesar la aplicación que causa el el tamaño de tu HTML será más grande. Este no es un factor crítico, pero dependiendo de lo que se va a cargar, puede volverse engorroso.
Restricciones al usar la representación del lado del servidor
Uno de los mayores problemas que tuve al usar SSR fue cuando usé bibliotecas de terceros, que representan los componentes necesarios para acceder a ciertas variables que solo están disponibles en el navegador, estoy hablando de ellas window, document así sucesivamente. Uno de los hacks que necesitaba era simular un entorno DOM en el nodo con el JS-DOM, con esto los errores se detenían, pero el renderizado seguía siendo limitado.
Otra cosa es que en Vue.js hay algunos métodos de ciclo de vida que conocemos como (enlaces de ciclo de vida), que solo se llaman en el navegador (beforeMounte & mounted), si representa algo que se desencadena por estos enlaces, esto no ocurrirá en el servidor.
¿Qué Tenemos Para Una Aplicación SSR Con Vue?Js?
Nuxt Framework
Nuxt es un marco para crear aplicaciones universales con Vue.js, y llegó a resolver la espantosa tarea de hacer toda la configuración necesaria para usar la representación del lado del servidor con Vue.js, inspirado en Next.js que es un marco universal hecho para ReactJS.
Ya se puede considerar como un marco oficial de Vue.js para las aplicaciones de RSS, pero va más allá. Es una comunidad que está creando un ecosistema de módulos específicos orientados a este tipo de enfoque, ofrece una experiencia de desarrollo simple para que usted escriba los componentes del archivo vue. También ofrece funciones interesantes que ayudan en el desarrollo, como datos asincrónicos, middleware, diseño, etc.
Además, tiene un generador de sitios estático que usa prerender-spa-plugin y genera las páginas de su aplicación SPA sin necesidad del servidor. Una nota importante es que no representa páginas dinámicas. Si tiene un blog, es mejor usar SSR.
Conclusión
Usar esta tecnología tiene múltiples espacios de uso donde podemos implementarlo y mejorar experiencia de nuestros usuarios. Es una tecnología de la mano de uno de los frameworks JavaScript más populares, con lo cual, puedes hacerte de un stack de desarrollo muy interesante. Espero que este post te haya gustado. Nos vemos en el siguiente. Happy Hacking!
