(
Ilustración )
Érase una vez Hace unos años, cuando comenzaba a trabajar con la web en Java, trabajamos con JSP. Toda la página se generó en el servidor y se envió al cliente. Pero entonces surgió la pregunta de que la respuesta llegó demasiado tiempo ...
Comenzamos a utilizar un enfoque en el que se proporciona una plantilla de página vacía, y Ajax ya carga gradualmente todos los datos. Todos estaban felices, mostraban las páginas. No nos hemos dado cuenta de lo que hemos hecho por nosotros mismos, ya que la CSR afecta negativamente la optimización y el rendimiento de los motores de búsqueda en los dispositivos móviles. Pero luego escuché nuevamente sobre el soporte de SSR con los marcos JS.
¿Y qué pasa, la historia se repite?¿Cuáles son los principios operativos de SSR?1. Pre-rendición. En el caso más simple, se generan N archivos HTML, que se colocan en el servidor y se devuelven tal cual, es decir, se devuelve estática, no generamos nada durante la solicitud.
2. Como en el caso de JSP, el servidor genera HTML completo con todo el contenido y regresa al cliente. Pero, para no generar una página para cada solicitud (puede haber un millón de ellas y nuestro servidor se doblará), agreguemos un caché proxy. Por ejemplo, barniz.
¿Cuándo puede ser aplicable cada uno de estos métodos?1. ¿Cuándo tiene sentido generar un montón de archivos HTML? Obviamente, cuando los datos en el sitio cambian un poco menos que nunca. Por ejemplo, el sitio web corporativo de un puesto de reparación de calzado, que está a la vuelta de la esquina (sí, ese tío que cambia los talones en un puesto de 2x2 metros, también quería el sitio web de la compañía y, por supuesto, la página de la misión de la compañía). Para tal sitio, ni siquiera tiene que molestarse con marcos, SSR y otros silbatos, pero este es un ejemplo esférico. ¿Qué pasa si tenemos un blog con 1k publicaciones? A veces los actualizamos, a veces agregamos otros nuevos. Generar 1k + archivos estáticos ... Algo está mal. Y si cambiamos la publicación, entonces necesitamos regenerar un determinado archivo. Hmm ...
2. Y aquí el segundo método nos conviene. Donde generamos la primera vez sobre la marcha, y luego almacenamos en caché la respuesta en el servicio proxy. El tiempo de almacenamiento en caché puede ser una hora / dos / día, lo que sea. Si tenemos 10,000 llamadas por hora por publicación (increíble, ¿verdad?), Entonces solo la primera solicitud llegará al servidor. El resto recibirá una copia en caché en respuesta, y es más probable que nuestro servidor viva. En caso de actualizar una publicación, solo necesitamos restablecer el registro en caché para que la página siguiente genere una página real.
De las palabras a la acción:
Hola repo mundial.
0) generar hola mundo
Para un inicio rápido, la comunidad Nuxt ha preparado
plantillas básicas , puede instalar cualquiera de ellas con el comando:
$ vue init <template-name> <project-name>
Por defecto, se propone plantilla iniciada, y la tomaremos como ejemplo. Aunque en una aplicación real elegimos express-template. Llamemos al proyecto sencillo:
$ vue init nuxt-community/starter-template habr-nuxt-example $ cd habr-nuxt-example $ yarn # npm install, $ yarn dev
Muy bien , generamos hola mundo. Al recorrer la url, puede ver la página generada:
1) Webpack y Linting
Nuxt listo para usar ha configurado paquetes web con soporte para ES6 (babel-loader), componentes Vue de un solo archivo (vue-loader), así como SCSS, JSX y más.
Si estas capacidades no son suficientes, la configuración del paquete web se puede ampliar. Vamos a nuxt.config.js, y en build.extend tenemos la capacidad de modificar la configuración.
Por ejemplo, agregaremos un forro de estilo por analogía con la alineación de código, un punto importante, en nuestra opinión, para mantener una base de código uniforme. Este es un buen hábito que ayudará a evitar muchas dificultades.
Un ejemplo de una extensión de configuración (conectando un archivo de configuración para una criada basada en una variable de entorno):
config.plugins.push( new StylelintPlugin({ files: [ '**/*.vue', 'assets/scss/**/*.scss' ], configFile: './.stylelintrc.dev.js' }) )
Se pueden ver otros cambios en el repositorio por
etiqueta , estos cambios nos ayudarán a mantener los estilos en orden.
Y un ejemplo de un archivo de configuración de linter: usamos Standard JS, como una solución generalmente aceptada en Vue / Nuxt:
... extends: [ - 'plugin:vue/essential' + 'standard', + 'plugin:vue/recommended' ], …
2) Para un ejemplo de trabajo con datos, utilizaremos
esta API :
Conecte Axios como un complemento, cree un nuevo archivo en el directorio de complementos:
import * as axios from 'axios' let options = {}
Y un ejemplo de uso:
import axios from '~/plugins/axios' export default { async asyncData ({ params }) { const { data } = await axios.get('https://jsonplaceholder.typicode.com/posts') return { data } } }
De lo contrario, nabo por
etiqueta .
Descargar números:
1) SSR + Barniz
Primera solicitud:
Segundo:
2) No-ssr
La segunda solicitud de fastley
Una página en blanco llegó rápidamente, pero tardó 2 segundos en generar contenido.
Conclusión
Cual es el resultado? Descubrimos cómo obtener una aplicación SSR de inicio mínimamente configurada. Agregaron Linting para preservar el estilo del código desde el comienzo de la vida del proyecto, y también describieron la arquitectura general. Puedes escribir tu googol.
