No React, aplicativos isomórficos referem-se a aplicativos que compartilham código completo ou parcial entre o cliente e o servidor e também podem ser chamados de aplicativos JavaScript isomórficos que não requerem renderização de conteúdo no lado do navegador, mas alcançam um equilíbrio entre o lado do servidor e o lado do servidor; renderização no lado do navegador, gerar conteúdo de renderização no servidor e permitir que os usuários vejam páginas com informações o mais cedo possível.
O ambiente operacional deste tutorial: sistema Windows 10, react versão 17.0.1, computador Dell G3.
Aplicativos isomórficos, também conhecidos como aplicativos JavaScript universais, referem-se a aplicativos que compartilham código total (ou parcialmente) entre o cliente e o servidor. Ao executar o código JavaScript do aplicativo no lado do servidor, a página pode ser pré-preenchida com conteúdo antes de ser enviada ao navegador, para que os usuários possam ver o conteúdo antes mesmo de o JavaScript do navegador ser executado. Quando o JavaScript local estiver em execução, ele assumirá as operações subsequentes de interação e navegação, permitindo que os usuários obtenham uma experiência interativa tranquila em aplicativos de página única por meio de carregamento inicial rápido e renderização de página no servidor.
O que é isomorfismo
Com o surgimento repentino do Node.js, o desenvolvimento front-end e back-end tem a base de uma linguagem de programação padronizada, modelos de página, mecanismos de dependência de terceiros, etc., todos têm oportunidades para realizar a unificação de front-end e back-end. -fim. React foi o primeiro a liderar essa tendência, e o conceito de isomorfismo se espalhou mais amplamente.
O que os leitores precisam entender é que os aplicativos isomórficos não exigem renderização de conteúdo no lado do navegador, mas sim alcançar um equilíbrio entre a renderização no lado do servidor e no lado do navegador. Então, como entender esse equilíbrio?
Gere conteúdo de renderização no servidor para que os usuários possam ver as páginas informativas o mais cedo possível. Além do conteúdo estático puro, um aplicativo completo também inclui diversas respostas a eventos, interações do usuário, etc. Isso significa que os scripts JavaScript devem ser executados no lado do navegador para concluir trabalhos como vincular eventos e lidar com interações assíncronas.
Do ponto de vista do desempenho e da experiência do usuário, a renderização do lado do servidor deve expressar as informações mais importantes, essenciais e básicas da página, enquanto o lado do navegador precisa concluir a renderização adicional da página, vinculação de eventos e outras funções aprimoradas para interação; O chamado isomorfismo significa que os front-ends e back-ends compartilham um conjunto de código ou lógica. Nesse conjunto de código ou lógica, a situação ideal é julgar a estrutura DOM existente e a estrutura a ser renderizada durante o processo de renderização posterior. o lado do navegador. É o mesmo? Em caso afirmativo, a estrutura do DOM não será renderizada novamente, apenas a ligação de eventos será necessária.
Nesta dimensão, o isomorfismo é diferente da renderização do lado do servidor. O isomorfismo é mais parecido com a interseção da renderização do lado do servidor e da renderização do lado do navegador. Ele compensa as diferenças entre o lado do servidor e o lado do navegador, de modo que o mesmo. conjunto de código ou A lógica pode ser unificada. O núcleo do isomorfismo é "o mesmo conjunto de códigos", que é outra dimensão separada dos ângulos em ambas as extremidades.
Vantagens e desvantagens do isomorfismo
As vantagens do isomorfismo são as seguintes:
Melhor desempenho. O desempenho aqui se refere principalmente à renderização mais rápida, tempo de exibição da primeira tela mais rápido, menos arquivos e tamanho de arquivo menor.
Suporte para otimização de SEO. Depois de receber a solicitação, o servidor retornará um documento HTML relativamente completo contendo o conteúdo inicial, o que é mais propício para os rastreadores dos mecanismos de busca obterem informações e melhorarem as classificações de exibição dos resultados da pesquisa. Ao mesmo tempo, tempos de carregamento de página mais rápidos também ajudarão a melhorar as classificações de exibição dos resultados de pesquisa.
A implementação é mais flexível. A renderização do lado do servidor produz apenas o conteúdo inicial da página, e o navegador ainda precisa fazer um trabalho de acompanhamento para concluir a apresentação final da página. Dessa forma, a renderização do lado do servidor e do lado do navegador ainda podem ser equilibradas e a reutilização de código pode ser alcançada em grande medida.
Mais sustentável. Porque com a ajuda de bibliotecas como React, conseguimos uma ampla gama de reutilização de código, evitando a necessidade de o servidor e o navegador manterem dois conjuntos de código ou lógica ao mesmo tempo. Como resultado, o volume geral de código é menor e os custos de manutenção são menores.
Mais amigável para modelos low-end. Como a renderização inicial do conteúdo é concluída no lado do servidor, é mais amigável para modelos de baixo custo e não causará uma tela branca quando a página for carregada.
Mais amigável para ambientes de rede adversos. No método tradicional de separação de front-end e back-end, o conteúdo da página será exibido somente depois que todos os scripts JavaScript forem baixados e executados. Um grande número de solicitações de rede foi experimentado no processo. sem dúvida aumenta a dificuldade de renderização do conteúdo básico da página. A este respeito, as aplicações isomórficas apresentam claramente vantagens.
Melhor experiência do usuário. Para equilibrar de forma mais razoável o conteúdo de renderização do lado do servidor e do lado do navegador, podemos projetar as partes principais importantes da página para serem concluídas no lado do servidor, enquanto as partes interativas menos importantes podem ser renderizadas pelo navegador ou após o conteúdo mais importante é renderizado. A implementação melhorará muito a experiência do usuário.
As desvantagens do isomorfismo são as seguintes:
A lógica de processamento do lado do servidor aumenta, aumentando a complexidade.
O servidor não pode reutilizar completamente o código do navegador.
Adicionado tempo TTFB (Time To First Byte) no lado do servidor. O tempo TTFB refere-se ao tempo desde o momento em que o navegador inicia a solicitação inicial da rede até o momento em que o primeiro byte é recebido do servidor. Ele contém o tempo de conexão TCP, o tempo para enviar a solicitação HTTP e o tempo para obter o primeiro byte da mensagem de resposta. Porque a aquisição de dados e a renderização do conteúdo inicial da página irão inevitavelmente reduzir a velocidade de retorno do servidor.
Amplie seu conhecimento:
Design de arquitetura front-end e back-end e conceitos de renderização no lado do servidor
O conceito de renderização ou drop-in do lado do servidor está se tornando cada vez mais popular. Antes de entender como implementar a renderização do lado do servidor com base no React, é necessário que tenhamos uma compreensão geral do “passado e presente” da renderização do lado do servidor no nível arquitetônico: por que tal conceito aparece, quais problemas podem ser; resolvido após a implementação desse conceito; renderização no lado do servidor e quais são os prós e contras de outros métodos?
A evolução da tecnologia de cooperação front-end e back-end
Nos primeiros dias do desenvolvimento Web, o design da arquitetura era simples e direto. Especificamente, a página era gerada no lado do servidor por JSP, PHP e outros engenheiros, e o navegador era responsável apenas por exibi-la. Naquela época, o engenheiro front-end só precisava adicionar alguns efeitos interativos dinâmicos à página estática e raramente envolvia lógica de dados, etc., enquanto o engenheiro back-end era responsável pelo conteúdo da página, ou seja, quando o usuário; solicitou a página, o back-end a processou e retornou a página estática completa. Esses processos geralmente dependem de mecanismos de modelo para serem concluídos. Então, naquela época, não havia nem mesmo um cargo separado de engenheiro front-end. Mesmo que existam, as deficiências desta abordagem são óbvias, tais como a divisão pouco clara de responsabilidades entre a frente e a retaguarda.
Se o pessoal de front-end desenvolver modelos, o front-end será extremamente dependente do ambiente de back-end, dificultando a maximização da eficiência do desenvolvimento. Ao mesmo tempo, o custo da comunicação sobre os formatos de dados será relativamente alto. Além disso, tal modelo arquitetônico tem espaço muito limitado para o desenvolvimento de tecnologia front-end e o uso de recursos de navegador.
Com o rápido desenvolvimento da tecnologia front-end, especialmente o surgimento de tecnologias como AJAX e Node.js, surgiu um modelo de arquitetura que separa o front-end e o back-end. Nesse modo, a divisão de trabalho entre front e back-end torna-se muito clara, e o principal ponto de colaboração em ambas as extremidades é a interface AJAX. Vamos tomar como exemplo a página de acesso do usuário para entender esse modelo passo a passo, conforme mostra a figura abaixo.
