(
Ilustração )
Era uma vez Há alguns anos, quando eu estava começando a trabalhar com a web em Java, trabalhamos com JSP. A página inteira foi gerada no servidor e enviada ao cliente. Mas então surgiu a pergunta de que a resposta veio longa demais ...
Começamos a usar uma abordagem na qual um modelo de página vazio é fornecido e todos os dados já são gradualmente carregados pelo Ajax. Todo mundo estava feliz, mostraram as páginas. Não percebemos o que fizemos por nós mesmos, pois o CSR afeta negativamente a otimização e o desempenho dos mecanismos de pesquisa em dispositivos móveis. Mas ouvi novamente sobre o suporte ao SSR com estruturas JS.
E o que acontece, a história se repete?Quais são os princípios operacionais do SSR?1. Pré-renderização. No caso mais simples, N arquivos HTML são gerados, que são colocados no servidor e retornados como estão - ou seja, a estática é retornada, não geramos nada durante a solicitação.
2. Como no caso do JSP, o servidor gera HTML completo com todo o conteúdo e o retorna ao cliente. Mas, para não gerar uma página para cada solicitação (pode haver um milhão delas e nosso servidor será dobrado), vamos adicionar um cache proxy. Por exemplo, verniz.
Quando cada um desses métodos pode ser aplicável:1. Quando faz sentido gerar um monte de arquivos HTML? Obviamente, quando os dados no site mudam um pouco menos do que nunca. Por exemplo, o site corporativo de uma barraca de conserto de calçados, que fica ao virar da esquina (sim, o tio que troca de salto em uma barraca de 2x2 metros também queria o site da empresa - e, é claro, com a página de missão da empresa). Para um site como esse, você nem precisa se preocupar com estruturas, SSRs e outros assobios, mas este é um exemplo esférico. E se tivermos um blog com 1k posts? Às vezes os atualizamos, às vezes adicionamos novos. Gere 1k + arquivos estáticos ... Algo está errado. E se mudarmos a postagem, precisamos gerar novamente um determinado arquivo. Hmm ...
2. E aqui o segundo método nos convém. Onde geramos a primeira vez em tempo real e, em seguida, armazenamos em cache a resposta no serviço de proxy. O tempo de armazenamento em cache pode ser de uma hora / dois / dia - qualquer que seja. Se tivermos 10.000 chamadas por hora por postagem (inacreditável, certo?), Somente a primeira solicitação chegará ao servidor. O restante receberá uma cópia em cache em resposta, e é mais provável que nosso servidor viva. No caso de atualizar uma postagem, basta redefinir o registro em cache para que a próxima página gere uma página real.
Das palavras à ação:
Olá repo mundo.
0) gerar olá mundo
Para começar rapidamente, a comunidade Nuxt preparou
modelos básicos , você pode instalar qualquer um deles com o comando:
$ vue init <template-name> <project-name>
Por padrão, o modelo iniciado é proposto e o usaremos como exemplo. Embora em uma aplicação real tenhamos escolhido express-template. Vamos chamar o projeto diretamente:
$ vue init nuxt-community/starter-template habr-nuxt-example $ cd habr-nuxt-example $ yarn # npm install, $ yarn dev
Tudo bem , nós geramos olá mundo. Percorrendo o URL, você pode ver a página gerada:
1) Webpack e Linting
O Nuxt pronto para o uso configurou pacotes da web com suporte para ES6 (babel-loader), componentes de arquivo único do Vue (vue-loader), além de SCSS, JSX e mais.
Se esses recursos não forem suficientes, a configuração do webpack poderá ser expandida. Vamos para o nuxt.config.js, e no build.extend temos a capacidade de modificar a configuração.
Por exemplo, adicionaremos estilo de alinhamento por analogia com código de fiação - um ponto importante, em nossa opinião, para manter uma base de código uniforme. Este é um bom hábito que ajudará a evitar muitas armadilhas.
Um exemplo de extensão de configuração (conectando um arquivo de configuração para uma empregada doméstica com base em uma variável de ambiente):
config.plugins.push( new StylelintPlugin({ files: [ '**/*.vue', 'assets/scss/**/*.scss' ], configFile: './.stylelintrc.dev.js' }) )
Outras alterações podem ser visualizadas no repositório por
tag . Essas alterações nos ajudarão a manter os estilos em ordem.
E um exemplo de um arquivo de configuração de linter: usamos o Standard JS, como uma solução geralmente aceita no Vue / Nuxt:
... extends: [ - 'plugin:vue/essential' + 'standard', + 'plugin:vue/recommended' ], …
2) Para um exemplo de trabalho com dados, usaremos
esta API :
Conecte o Axios como um plug-in, crie um novo arquivo no diretório plug-ins:
import * as axios from 'axios' let options = {}
E um exemplo de uso:
import axios from '~/plugins/axios' export default { async asyncData ({ params }) { const { data } = await axios.get('https://jsonplaceholder.typicode.com/posts') return { data } } }
Senão em nabo por
etiqueta .
Números de download:
1) SSR + verniz
Primeiro pedido:
Segundo:
2) No-ssr
O segundo pedido de fastley
Uma página em branco chegou rapidamente, mas demorou 2 segundos para gerar conteúdo nela.
Conclusão
Qual é o resultado? Nós descobrimos como obter um aplicativo SSR de inicialização minimamente configurado. Eles adicionaram o Linting para preservar o estilo do código desde o início da vida do projeto e também descreveram a arquitetura geral. Você pode escrever seu googol.
